| << Back to previous view |
|
[BPMNFTF-592] [AB feedback] Inventory file
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivana Trickovic | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Feedback from Steve Cook, Microsoft:
Comment: I am not sure about the document numbers on the file inventory. It says the no change bars version is dtc/2010-05-24. Is this correct? Shouldn't it be 2010-05-03? - The uploaded document is not up-to-date - The document the FTF submitted on 5/24 is still correct - Juergen to be asked to upload the correct version |
| Comments |
| Comment by Ivana Trickovic [ 11/Jun/10 11:05 AM ] |
|
spec-May24-review
|
| Comment by Ivana Trickovic [ 11/Jun/10 11:06 AM ] |
|
As per the 6/7 meeting:
The uploaded document is not up-to-date - The document the FTF submitted on 5/24 is still correct - Juergen to be asked to upload the correct version |
[BPMNFTF-591] [AB feedback] Alignment with Diagram Definition specification
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivana Trickovic | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Feedback from Steve Cook, Microsoft
Comment: Section 15.4 of the spec says "The BPMN 2.0 XMI for the interchange of diagram information will be published once the OMG Diagram Definition RFP process has produced a specification that is sufficiently complete such that the BPMN 2.0 FTF can align the BPMN 2.0 specification with the Diagram Definition specification." I don't understand how this it possible: presumably the BPMN 2.0 FTF ceases to exist now? Please clarify the process for alignment with Diagram Definition, and how this will be documented in the spec. |
| Comments |
| Comment by Ivana Trickovic [ 11/Jun/10 11:03 AM ] |
| spec-May24-review |
| Comment by Ivana Trickovic [ 11/Jun/10 11:03 AM ] |
|
As per the 6/7 meeting:
We agree that the text should be modified. It shall clarify that this alignment can be done as part of a future version (or a future activity - RFP/FTF/RTF) |
[BPMNFTF-590] [AB feedback] Status of the non-normative examples document
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivana Trickovic | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Feedback from Steve Cook, Microsoft
Comment: The front page of the report promises a non-normative document with examples. What is the status of this? |
| Comments |
| Comment by Ivana Trickovic [ 11/Jun/10 10:45 AM ] |
|
spec-May24-review
|
| Comment by Ivana Trickovic [ 11/Jun/10 10:47 AM ] |
| As per the 6/7 meeting: Status to be provided in a separate email. |
[BPMNFTF-589] OMG Issue Created 15284
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | BPMN 2.0 FTF |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
>From: webmaster@omg.org >Date: 08 Jun 2010 22:39:26 -0400 >To: <issues@omg.org> >Subject: Issue/Bug Report > >******************************************************************************* >Name: Stephen White >Company: IBM >mailFrom: wstephe@us.ibm.com >Notification: No >Specification: BPMN 2.0 >Section: 9.6 >FormalNumber: dtc/2010-05-03 >Version: 2.0 (Convenience) >RevisionDate: May 2010 >Page: 139 (169 pdf) >Title: Clarify Relationship between Collabration Message >Flow and Choreography Tasks >Nature: Clarification >Severity: Minor >test: 3qw8 >B1: Report Issue > >Description: > >When a Choreography is included in a Collaboration, the spec says >that Message Flow can be "wired up" to Choreography Tasks. This >needs to be defined better. Are the objects connected or >overlapping? What if the Choreography Task moves, etc. [Created via e-mail received from: Juergen Boldt <juergen@omg.org>] |
[BPMNFTF-588] The cover section to be updated
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivana Trickovic | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Regarding the cover section:
The following list is already included in the specification (these companies contributed to the BPMN 2.0 proposal submitted to OMG in May 2009): Copyright © 2009, Axway Copyright © 2009, BizAgi Copyright © 2009, Bruce Silver Associates Copyright © 2009, IDS Scheer Copyright © 2009, IBM Corp. Copyright © 2009, MEGA International Copyright © 2009, Model Driven Solutions Copyright © 2009, Object Management Group Copyright © 2009, Oracle Copyright © 2009, SAP AG Copyright © 2009, Software AG Copyright © 2009, TIBCO Software Copyright © 2009, Unisys Based on the email exchange with Andrew Watson from OMG at least the following companies *shall be added* to this list as their representatives provided (text) contributions to the FTF: Adaptive CA Inc. Camunda Services GmbH Cordys Fujitsu Global 360, Inc. Hewlett-Packard iGrafx Inferware Intalio Lombardi Software NIST oose Innovative Informatik GmbH PNA Group Red Hat Trisotech Of course, adding all FTF Voting members would not be incorrect. This would include the following companies: BAE SYSTEMS DICOM France Telecom R&D KnowGravity Inc. MITRE No Magic, Inc. Softeam Software AG Inc. Visumpoint |
| Comments |
| Comment by Ivana Trickovic [ 04/Jun/10 10:12 AM ] |
| spec-May24-review |
| Comment by Ivana Trickovic [ 14/Jun/10 06:04 AM ] |
|
Based on the feedback from OMG
Change "Copyright © 2009, <company name>" to "Copyright © 2010, <company name> " |
| Comment by Ivana Trickovic [ 14/Jun/10 09:03 AM ] |
|
Request from Robert Shapiro:
Scott Schanel (iGrafx) and Bruce Silver both made significant contributions to the DI xsd work by working out a prototype xsd that eliminated redundancies and simplified the constructs. I believe these helped point the way to what could be achieved that was useful for the subgroup. Can their contribution be acknowledged in the final document? |
[BPMNFTF-587] OMG Issue Created 15256
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | BPMN 2.0 FTF |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
>From: webmaster@omg.org >Date: 17 May 2010 23:21:45 -0400 >To: <issues@omg.org> >Subject: Issue/Bug Report > >******************************************************************************* >Name: Karsten Ploesser >Company: SAP Australia Pty Ltd >mailFrom: karsten.ploesser@sap.com >Notification: Yes >Specification: Business Process Model and Notation >Section: 10.2.5 >FormalNumber: dtc/2010-05-02 >Version: Version 2.0 Draft 3 >RevisionDate: 05/02/2010 >Page: 155-178 >Title: CorrelationSubscription Ownership - Sub Process >Nature: Revision >Severity: Critical >test: 3qw8 >B1: Report Issue > >Description: > >Currently only Processes can 'own' Correlation Subscriptions. >However, also Sub Processes should be able to define and own >Correlation Subscriptions. > >Use case: restrict the lifecycle of the correlation subscription to >the sub process only (as opposed to activating the subscription for >the entire lifecycle of the process. This is particularly required >in the case of long running processes. > >Proposed resolution: >Figure 10.29- The Sub-Process class diagram >Table 10.20 - Sub-Process attributes >Table 10.48 - SubProcess XML schema > > ADD attribute correlationSubscriptions:CorrelationSubscription > [0..*] to class Sub-Process Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org <http://www.omg.org/signature.htm> [Created via e-mail received from: Juergen Boldt <juergen@omg.org>] |
[BPMNFTF-586] OMG Issue Created 15255
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | BPMN 2.0 FTF |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
>From: webmaster@omg.org >Date: 17 May 2010 20:40:47 -0400 >To: <issues@omg.org> >Subject: Issue/Bug Report > >******************************************************************************* >Name: Stephen A. White >Company: IBM >mailFrom: wstephe@us.ibm.com >Notification: No >Specification: BPMN 2.0 Beta >Section: Chapter 10.2 >FormalNumber: dtc/2009-08-14 >Version: Beta 1 >RevisionDate: August 2009 >Page: 127 >Title: Define rules for placement of multiple activity markers >Nature: Clarification >Severity: Minor >test: 3qw8 >B1: Report Issue > >Description: > >A Task or Sub-Process may have multiple markers (e.g., looping, >compensation, etc.). But the spec does not explicitly define how the >markers should be ordered. The examples in the spec are not >consistent in how they are presented. [Created via e-mail received from: Juergen Boldt <juergen@omg.org>] |
[BPMNFTF-585] [OMG 15253] Data associations need to be revisited and their use clarified.
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | BPMN 2.0 FTF |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Name: Denis Gagne
Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.3.1 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 228-231 Title: Data Associations Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Data associations need to be revisited and their use clarified. Data association should have there own visual depiction. Using the look of association is misleading as data associations have a different meaning than associations. A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they? This is not clear. It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools. |
[BPMNFTF-584] [OMG 15217] Add Link Events to a sub-conformance level (Descriptive)
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 2 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 1 Title: Add Link Events to a sub-conformance level (Descriptive) Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events. |
[BPMNFTF-583] Rename current namespaces to follow OMG Guidelines
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
The XML namespaces must be renamed to follow OMG guidelines, which is date based.
Copying Tom Rutt's comment on I have a concern about the namespace URLs being proposed. (Pete Rivett has raised a similar concern on Issue 456) I note that there is a dated uri for the di namespace, which is a good thing.. However the namespace for bpmndi.xsd is not dated, but has a bpmn version number. I wonder why the bpmndi.xsd does not use a dated namespace uri? That way if the next version has a compatible namespace change, we do not have to change the namepsace uri. see the smsc namespace policy document: http://www.omg.org/members/cgi-bin/doc?smsc/09-09-07.doc |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 04:59 PM ] |
| this is not an OMG issue, we do not need to vote on it. |
[BPMNFTF-582] [OMG 15171] Messages and User Tasks
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 145 Title: Messages and User Tasks Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks. Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types |
[BPMNFTF-581] [OMG 15169] The Two Multi-Instance Markers should be reversed
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Notation, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 170 Title: The Two Multi-Instance Markers should be reversed Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: The two versions of the Multi-Instance loop marker should be reversed. The three horizontal lines looks more like parallism and the three vertical lines look more like sequentialism. |
| Comments |
| Comment by Reiner Hille-Doering [ 13/Apr/10 03:31 AM ] |
|
Counter proposal
##Proposed Resolution: Close no change Reason: Changing the icon for multi-instance activities now will cause a lot of confusions. It will be difficult to ensure that the whole document stays in a consistent state. There are also already publications out on the market that use the current notation. Even for BPMN 1.x there are examples that use the current "vertical" notation for parallel, e.g. see Steves http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf , Figure 30. So, there would be some kind of incompatibility introduced. Which orientation is better to understand for parallel and sequential depends mainly on taste on which axis one assumes time. If you model vertically top to bottom, the current notation is good. This is similar like writing a text, or also similar to UML activity and sequence diagrams. Only for the case that you model left-to-right the other proposal might make little more sense. Conclusion: Changing the meaning now has much higher risk than advantages. |
| Comment by Falko Menge [ 13/Apr/10 04:38 AM ] |
| We at camunda strongly agree with Reiners proposal. The interpretation of the directions of the lines in these icons depends on the cultural background of a reader. Hence, this is just a matter of taste and not an issue in the specification, which the FTF needs to fix. |
| Comment by Denis Gagne [ 13/Apr/10 12:23 PM ] |
| We also feel that there shold be no change to the spec as per Reiner arguments. |
[BPMNFTF-580] [OMG 15168] A Collaboration should be able to reference more than one Choreography
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema, SoaML |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 9 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 111 Title: A Collaboration should be able to reference more than one Choreography Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: To support SoaML modeling a Collaboration will need to be able to reference more than one Choreographies. These Choreographies would then be associated with the Conversations of the Collaboration. ##Proposed Resolution: Fixed Section 9, Collaboration Change the multiplicity of Collaboration's choreographyRef model association from 0..1 to 0..* (a) Update Figure 9.1 to reflect this change Table 9.1, second row: (b) First column: Change "[0..1]" to "[0..*]" (c) Second column: change the first sentence to "The choreographyRef model association defines the Choreographies that can be shown between the Pools of the Collaboration." (d) Table 9.2, Collaboration XML Schema: change: "<xsd:attribute name="choreographyRef" type="xsd:QName" use="optional"/>" To "<xsd:element ref="choreographyRef " minOccurs="0" maxOccurs="unbounded"/>" |
[BPMNFTF-579] [OMG 15165] Conversation lanes
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration, SoaML |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jim Amsden | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Jim Amsden Company: IBM mailFrom: jamsden@us.ibm.com Notification: No Specification: BPMN 2 Section: Conversations FormalNumber: dtc/09-08-14 Version: RevisionDate: Page: Title: Conversation lanes Nature: Revision Severity: Minor test: 3qw8 B1: Report Issue Description: Lanes representing conversations should require activities in those lanes to send or receive message flows in the conversation. |
| Comments |
| Comment by Conrad Bock (NIST) [ 12/Apr/10 12:20 PM ] |
|
-----------Proposal----------------Apr 12, 2010---------------------------
##Proposed Resolution: Fixed The resolution assumes the resolution of In the Collaborations chapter, Conversations section, at the end of the Conversation Link subsection, add the paragraph When a lane represents a conversation, the flow elements in the lane (or elements nested or called in them) that send or receive messages must do so as part of the conversation represented by the lane. |
[BPMNFTF-578] [OMG 15163] Missing definition of the participant Buyer
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Gerardo Navarro Suarez Company: Camunda Services GmbH mailFrom: gerardo.navarro-suarez@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 10 Process FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 150 -152 (180 - 182) Title: Missing definition of the participant Buyer Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Table 10.19, the XML serialization of the Buyer process in figure 10.23 (pg. 150) is shown. The process model in figure 10.23 shows a Pool named Buyer. The metamodell provides the possibility to define pools as participants, which have a reference to the process definition. But Table 10.19 doesn't contain any definition of a participant. ----Proposal---------------- 04/07/2010 ------------------------- ##Proposed Resolution: Fixed (a) Update Table 10.19 by replacing the XML with the following XML,which adds a collaboration with a participant and a laneSet. The collaboration represents the pool Buyer in figure 10.23 (pg. 150). <definitions id="Definition" targetNamespace="http://www.example.org/UserTaskExample" typeLanguage="http://www.w3.org/2001/XMLSchema" expressionLanguage="http://www.w3.org/1999/XPath" xmlns="http://schema.omg.org/spec/BPMN/2.0" xmlns:tns="http://www.example.org/UserTaskExample"> <resource id="regionalManager" name="Regional Manager"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> <resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/> </resource> <resource id="departmentalReviewer" name="Departmental Reviewer"> <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/> </resource> <collaboration id="BuyerCollaboration" name="Buyer Collaboration"> <participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/> </collaboration> <!-- Process definition --> <process id="BuyerProcess" name="Buyer Process"> <laneSet id="BuyerLaneSet"> <lane id="ByerLane"> <flowElementRef>StartProcess</flowElementRef> <flowElementRef>QuotationHandling</flowElementRef> <flowElementRef>ApproveOrder</flowElementRef> <flowElementRef>OrderApprovedDecision</flowElementRef> <flowElementRef>TerminateProcess</flowElementRef> <flowElementRef>OrderAndShipment</flowElementRef> <flowElementRef>OrderHandling</flowElementRef> <flowElementRef>ShipmentHandling</flowElementRef> <flowElementRef>OrderAndShipmentMerge</flowElementRef> <flowElementRef>ReviewOrder</flowElementRef> <flowElementRef>EndProcess</flowElementRef> </lane> </laneSet> <startEvent id="StartProcess"/> <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/> <task id="QuotationHandling" name="Quotation Handling"/> <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/> <userTask id="ApproveOrder" name="ApproveOrder"> <potentialOwner resourceRef="tns:regionalManager"> <resourceParameterBinding parameterRef="tns:buyerName"> <formalExpression>getDataInput('order')/address/name</formalExpression> </resourceParameterBinding> <resourceParameterBinding parameterRef="tns:region"> <formalExpression>getDataInput('order')/address/country</formalExpression> </resourceParameterBinding> </potentialOwner> </userTask> <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/> <exclusiveGateway id="OrderApprovedDecision" gatewayDirection="diverging"/> <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment"> <conditionExpression>Was the Order Approved?</conditionExpression> </sequenceFlow> <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="TerminateProcess"> <conditionExpression>Was the Order NOT Approved?</conditionExpression> </sequenceFlow> <endEvent id="TerminateProcess"> <terminateEventDefinition id="TerminateEvent"/> </endEvent> <parallelGateway id="OrderAndShipment" gatewayDirection="diverging"/> <sequenceFlow sourceRef="OrderAndShipment" targetRef="OrderHandling"/> <sequenceFlow sourceRef="OrderAndShipment" targetRef="ShipmentHandling"/> <task id="OrderHandling" name="Order Handling"/> <task id="ShipmentHandling" name="Shipment Handling"/> <sequenceFlow sourceRef="OrderHandling" targetRef="OrderAndShipmentMerge"/> <sequenceFlow sourceRef="ShipmentHandling" targetRef="OrderAndShipmentMerge"/> <parallelGateway id="OrderAndShipmentMerge" gatewayDirection="converging"/> <sequenceFlow targetRef="OrderAndShipmentMerge" sourceRef="ReviewOrder"/> <userTask id="ReviewOrder" name="Review Order"> <potentialOwner resourceRef="tns:departmentalReviewer"> <resourceParameterBinding parameterRef="tns:buyerName"> <formalExpression>getDataInput('order')/address/name</formalExpression> </resourceParameterBinding> </potentialOwner> </userTask> <sequenceFlow sourceRef="ReviewOrder" targetRef="EndProcess"/> <endEvent id="EndProcess"/> </process> </definitions> |
| Comments |
| Comment by Falko Menge [ 12/Apr/10 08:20 AM ] |
| New Proposed Resolution |
| Comment by Falko Menge [ 08/Jun/10 01:19 PM ] |
|
spec-May24-review
The resolution of this issue has not been applied correctly. The 'collaboration' element in Table 10.19 is closed by a '</resource>' tag instead of a '</collaboration>' tag. Proposal: Replace '</resource>' with '</collaboration>' in the 'collaboration' element. |
| Comment by Falko Menge [ 09/Jun/10 05:59 AM ] |
|
spec-May24-review
The namespace prefix 'xsd' is not defined in the model. Proposal: Add the attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" to the 'definitions' element. |
| Comment by Stephen White [ 11/Jun/10 06:19 PM ] |
| completed fix for spec-May24-review comments |
[BPMNFTF-577] [OMG 15161] Exporter information required for BPMN 2 files
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange, General, Metamodel, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Document #: BPMN 2 Revision Date: May 22 Chapter/Section: 8 Version #: v 0.9.14 Page(s): 72-75 There is a requirement for the "Exporter" of a BPMN 2 file to be identified. Such identification will allow an importing tool to take various appropriate actions to ensure ease of exchange and interchange of BPMN 2 files (for both semantic and diagrams). There is substantial practical evidence of the benefits of such information. In fact XMI provides support for such information. You can refer to MOF 2.0/XMI Mapping Specification, v2.1.1, section 4.5.2 and section 4.5. in the XMI spec for description of the <documentation> class, which is part of the XMI model. It contains the nested element <exporter>, and <exporterVersion> which serves this purpose. The intention is that any model that is an instance of MOF and serialized in XMI is able to include an instance of <documentation> nested in the root. As the example given by Pete shows: More specifically there is the following in the XMI spec : <xsd:complexType name="Documentation"> ... <xsd:element name="exporter" type="xsd:string"/> <xsd:element name="exporterVersion" type="xsd:string"/> For example: <xmi:XMI> <documentation xmi:type=xmi:Documentation> <exporter>MagicDraw UML</exporter> <exporterVersion>16.8 Beta</exporterVersion> </documentation> ... This would require changes to section 8.1 and 8.1.3 of the BPMN 2 spec Proposal: Add to the tDefinitions xsd complexType: <xsd:attribute name="exporter" type="xsd:string" /> <xsd:attribute name="exporterVersion" type="xsd:string"/> This will give two new optional properties (exporter and exporterVersion). ##Proposed Resolution: Fixed (a) Add to the tDefinitions xsd complexType: "<xsd:attribute name="exporter" type="xsd:string" /> <xsd:attribute name="exporterVersion" type="xsd:string"/>" (b) Update Figure 8.4, Figure 8.5, and Figure 8.6 to reflect this change (c) Update Table 8.1 and Table 8.3 to include these attributes |
[BPMNFTF-576] [OMG 15159] Choreography activities sharing message flow
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2 Section: Choreography FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Choreography activities sharing message flow Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The spec allows multiple choreography activities to share the same message flow. Is that intended? |
[BPMNFTF-575] [OMG 15158] Lists of values
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
Name: Conrad Bock
Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: BPMN 2 Section: FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Lists of values Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The word "list" is used a fair amount in describing attributes and model associations. I think these are intended to be sets in most cases, rather than lists (no ordering, no duplicates). In UML, the default is sets, you need to add "{ordered}" "{non-unique}" to get lists. |
| Comments |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 02:55 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Defer This is a problem in the specification, but was noticed too late to address in the FTF. |
[BPMNFTF-574] [OMG 15155] Inclusive Gateway Semantics
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Hagen Volzer | Assigned To: | Hagen Volzer |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Inclusive+Complex-Gateway.doc
|
| Description |
|
Name: Hagen Voelzer
Company: IBM mailFrom: hvo@zurich.ibm.com Notification: Yes Specification: BPMN/2.0 Section: 14.3.2 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for 2.0 RevisionDate: Aug 2009 Page: 401 Title: Inclusive Gateway Semantics Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: In the current semantics description of the inclusive gateway: The Inclusive Gateway is activated if • At least one incoming sequence flow has at least one Token and• for each empty incoming sequence flow, there is no Token in the graph anywhere upstream of this sequence flow, i.e., there is no directed path (formed by Sequence Flow) from a Token to this sequence flow unless- the path visits the inclusive gateway or- the path visits a node that has a directed path to a non-empty incoming sequence flow of the inclusive gateway. it does not get clear that the latter path is also not allowed to visit the inclusive gateway. I suggest to reword the entire sentence. The same applies to the semantics of the complex gateway. ##Proposed Resolution: Fixed Table 14.3, first row, second column: replace the contents of the column with the following: "The Inclusive Gateway is activated if 1. At least one incoming sequence flow of the inclusive gateway has at least one Token and 2. for every directed path formed by sequence flow that i. starts with a sequence flow f of the diagram that has a Token, ii. ends with an incoming sequence flow of the inclusive gateway that has no Token, and iii. does not visit the inclusive gateway, there is also a directed path formed by sequence flow that iv. starts with f, v. ends with an incoming sequence flow of the inclusive gateway that has a Token, and vi. does not visit the inclusive gateway. If the inclusive gateway is contained in a sub-process, then no paths are considered that cross the boundary of that sub-process. Upon execution, a Token is consumed from each incoming sequence flow that has a Token. A Token will be produced on some of the outgoing sequence flows. In order to determine the outgoing sequence flows that receive a Token, all conditions on the outgoing sequence flows are evaluated. The evaluation does not have to respect a certain order. For every condition, which evaluates to true, a Token must be passed on the respective sequence flow. If and only if none of the conditions evaluates to true, the Token is passed on the default sequence flow. In case all conditions evaluate to false and a default flow has not been specified, the inclusive gateway throws an exception." |
| Comments |
| Comment by Hagen Volzer [ 07/Apr/10 11:32 AM ] |
|
My proposal for rewording is:
The Inclusive Gateway is activated if - at least one incoming sequence flow of the inclusive gateway has at least one Token and - for every directed path formed by sequence flow that i. starts in a sequence flow f that has a Token, ii. ends in an incoming sequence flow of the inclusive gateway that has no Token, and iii. does not visit the inclusive gateway, - there is also a directed path formed by sequence flow that i. starts in f, ii. ends in an incoming sequence flow of the inclusive gateway that has a Token, and iii. does not visit the inclusive gateway. I will add a similar rewording for the complex gateway. |
| Comment by Hagen Volzer [ 09/Apr/10 10:32 AM ] |
|
##Proposed Resolution: Fixed
See attached Word document for the precise rewording. I added also that the "scope" of an inclusive and complex gateway is the sub-process it is contained in. Furthermore, I added a comment that the semantics of the complex gateway implies that if the activationCondition never becomes true, tokens maybe blocked at the gateway, which may cause a deadlock of the process. |
[BPMNFTF-573] [OMG 15154] Missing Message Flow
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo.navarro-suarez@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 7 Overview FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 27 (57) Title: Missing Message Flow Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The last table record on page 27 (57) misses a picture of a message flow. The record "Nested/Embedded Sub-Process (Inline Block)" on page 32 (62) shows a message flow, which does't belong there. It might be the message flow missed on page 27 (57). ----Proposal------- 03/26/2010 -------------- ##Proposed Resolution: Fixed (a) Update the table record "Message Flow" in Table 7.2, inserting a figure of a message flow. Update table record Table 7.2 page 27 (57) (b) Update the table record "Nested/Embedded Sub-Process (Inline Block)" in Table 7.2, deleting the figure of the message flow. Update table record Table 7.2 page 32 (62) |
[BPMNFTF-572] [OMG 15152] Choreography is not enforcable
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Complex Logistics Example Choreography Beta 1.png
Complex Logistics Example Choreography Proposal 2010-03-25.png
Complex Logistics Example Collaboration Beta 1.png
Complex Logistics Example Collaboration Proposal 2010-03-25.png
Complex Logistics Example Proposal 2010-03-25.vsd
|
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo.navarro-suarez@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 12 Choreography FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 312 (342) Title: Choreography is not enforcable Nature: Clarification Severity: Critical test: 3qw8 B1: Report Issue Description: Figure 12.4; The Choreography model is not locally enforcable. In the last interaction the Supplier doesn't participate in the previous interaction. But in chapter 12.4.6 on page 328 (358) it is said: "The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous Choreography Activity." The lane in the middle of the Collaboration model (Figure 12.3 page 311 (341)) has a wrong name. It should be Supplier not Shipper. ----Proposal------- 03/25/2010 -------------- ##Proposed Resolution: Fixed (a) Update the Collaboration model, renaming the name of the lane in the middle of the model into "Supplier". Figure 12.3 page 311 (341) (b) Update the Choreography, changing the order of the last interactions. Put the fourth from last interaction "Accept PO and Delivery Schedule" right behind the last interaction "Finalized PO and Delivery Schedule". Figure 12.4 page 312 (342) (c) Update the Collaboration model, changing the position of the interaction between the Retailer and the Supplier about the message "PO & Delivery Schedule". Put the Send Message Task in the lane "Retailer" right behind the last Recieve Message Task in that lane. Figure 12.3 page 311 (341) (d) Update the last sentence in the paragraph under the Collaboration model. Exchange the 2 words "Retailer" and "Supplier". The sentence should look like this: "´accordingly, the Retailer interacts with the Consignee and Supplier for final confirmations." |
| Comments |
| Comment by Falko Menge [ 12/Apr/10 05:38 PM ] |
| The attached file 'Complex Logistics Example Proposal 2010-03-25.vsd' contains figures 12.3 and 12.4 updated as described in the proposal. |
| Comment by Falko Menge [ 12/Apr/10 05:43 PM ] |
| For better comparison, screenshots of the original diagrams ('Complex Logistics Example Choreography Beta 1.png' & 'Complex Logistics Example Collaboration Beta 1.png') and the proposal ('Complex Logistics Example Choreography Proposal 2010-03-25.png' & 'Complex Logistics Example Collaboration Proposal 2010-03-25.png') have been attached. |
| Comment by Falko Menge [ 14/May/10 08:16 PM ] |
|
Spec-Draft3-review
The issue resolution is not applied correctly. There is an unconnected duplicate of a send task in the center of Figure 11.3 in the third Draft. |
| Comment by Ivana Trickovic [ 17/May/10 03:39 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 19/May/10 09:32 PM ] |
| Done |
[BPMNFTF-571] [OMG 15150] Missing marker in Compensation Activity
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo.navarro-suarez@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 10 Process FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 255 (285) Title: Missing marker in Compensation Activity Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: In figure 10.97 the compensation subprocess "Undo Booking" doesn't have a compensation marker. In Chapter 10.6.1 of the specification the second paragraph says: "The Compensation Activity, which can be either a Task or a Sub-Process, has a marker to show that it is used for compensation only and is outside the normal flow of the Process." ---- Proposal ------- 03/25/2010 ------------ ##Proposed Resolution: Fixed (a) Insert the missing compensation marker on the left hand side of the Sub-Process marker. Updating figure 10.97 on page 255 (285) |
[BPMNFTF-570] [OMG 15149] Process Model and Model Description are not consistent
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo.navarro-suarez@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 11 Conversation FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 295 (325) Title: Process Model and Model Description are not consistent Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Figure 11.03; The Communication between Consignee Shipper and Consolidator has the name "Delivery / Dispatch Plan". But the description of the conversation model (below figure 11.3) says something else. In the Text this converstation is called "Detailed Shipment Schedule". Quotation out of the paragraph: "More than two participants may be involved in a Conversation, e.g., Consignee, Consolidator and Shipper in Detailed Shipment Schedule." ---- Proposal ------- 03/25/2010 ------------ ##Proposed Resolution: Fixed (a) Rename the Communication into "Detailed Shipment Schedule". |
| Comments |
| Comment by Falko Menge [ 14/May/10 08:20 PM ] |
|
Spec-Draft3-review
Draft 3 still contains the issue described here. |
| Comment by Ivana Trickovic [ 17/May/10 03:39 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 19/May/10 09:29 PM ] |
| Done |
[BPMNFTF-569] [OMG 15147] Missing
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 10 Process FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 150 (180) Title: Missing <sequenceFlow ... /> in XML example Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: On page 180 begins the serialized XML example (table 10.19) of the process model shown in figure 10.23 . The definition of a sequence flow is missing in the serialized XML. The process model has 11 flows, but in the XML example there are only 10 sequence flows defined. So one is missing. The missing flow is that one between AND - Join (called "OrderAndShipmentMerge") and the user task "Review order". ----Proposal------- 03/24/2010 -------------- ##Proposed Resolution: Fixed (a) Insert the following XML node into the example:<sequenceFlow sourceRef="OrderAndShipmentMerge" targetRef="ReviewOrder"/> Table 10.19 | Page 152 (182) (b) The best position would be on page 152 (182) between the tags <parallelGateway ...> and <userTask id="ReviewOrder" ...> . Table 10.19 | Page 152 (182) |
[BPMNFTF-568] [OMG 15146] Missing label of a compensation activity
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Gerardo Navarro Suarez
Company: Camunda Services GmbH mailFrom: gerardo@camunda.com Notification: Yes Specification: BPMN 2.0 Section: 10 Process FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 Draft 1 RevisionDate: Feb 2010 Page: 134 (166) Title: Missing label of a compensation activity Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Figure 10.9 contains three activities with different markers. 2 of them have a label above describing the type of the marker.But the activity on the right hand side misses it's label. This issue doesn't appear in the official Beta 1 from August 2009. So the issue appears only in the FTF Beta 1 for Version 2.0 Draft 1. ----Proposal------- 03/24/2010 -------------- ##Proposed Resolution: Fixed (a) Insert a label saying "Compensation". Position that label over the task with the compensation marker. Figure 10.9 | Page 134 (166) |
[BPMNFTF-567] [OMG 15139] Missing loopCharacteristics for Choreography stuff in MM
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Reiner Hille-Doering | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
12_choreography - Issue 567 V2.doc
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Name: Reiner Hille-Doering
Company: SAP mailFrom: reiner.hille-doering@sap.com Notification: No Specification: BPMN 2.0 Section: 12.4.1ff FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 316ff Title: Missing loopCharacteristics for Choreography stuff in MM Nature: Clarification Severity: Critical test: 3qw8 B1: Report Issue Description: The spec mentions in chapter 12.4.1ff loops for choreography elements, such as ChoreographyTasks, but in the metamodel none caries a loopCharacteristics. Normal orchestration activities inherit the attribute from the "Activity" class, but ChoreographyActivity does not inherit from Activity. ##Proposed Resolution: Fixed (a) Add a new attribute named loopType the is of the type ChoreographyLoopType enumeration for a Choreography Task. (b) Add a new enumeration named ChoreographyLoopType with four literals of None (default), Standard, MultiInstanceSequential, and MultiInstanceParallel (c) Update Figure 12.6 to include these changes Add a new row to Table 12.2 : (d) The first column of the new row should contain: "loopType: ChoreographyLoopType = None" (e) The second column of the new row should contain: "A Choreography Activity may be performed once or may be repeated. The loopType attribute will determine the appropriate marker for the Choreography Activity (see below)." Section 12.4.1, Page 318 (348 pdf): (f) 3rd bullet on page: change "two (2)" to "three (3)" (g) 4th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Task MUST be Standard" (h) 5th bullet on page: change "multi-instance" to "parallel multi-instance" (i) 5th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Task MUST be MultiInstanceParallel." (j) Add a new bullet after the 5th bullet with the following: "The marker for a Choreography Task that is sequential multi-instance MUST be a set of three horizontal lines. The loopType of the Choreography Task MUST be MultiInstanceSequential." (k) Update Figure 12.12 to show the sequential multi-instance marker. (l) Caption for Figure 12.14: Change "Multi-Instance" to "Parallel Multi-Instance" Section 12.4.2, Page 324 (354 pdf): (m) 3rd bullet on page: change "two (2)" to "three (3)" (n) 4th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Sub-Process MUST be Standard." (o) 5th bullet on page: change "multi-instance" to "parallel multi-instance" (p) 5th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Sub-Process MUST be MultiInstanceParallel." (q) Add a new bullet after the 5th bullet with the following: "The marker for a Choreography Sub-Process that is sequential multi-instance MUST be a set of three horizontal lines. The loopType of the Choreography Sub-Process MUST be MultiInstanceSequential." (r) Update Figure 12.22 to show the sequential multi-instance marker. (s) Section 12.4.5: add the following to the end of the first paragraph: "Examples of Choreography Activities with the appropriate markers can be seen in Figure 12.12 and Figure 12.22" (t) Table 12.11 Choreography Activity XML Schema: Add the following: "<xsd:attribute name="loopType" type="tChoreographyLoopType" default="Standard"/> ... <xsd:simpleType name="tChoreographyLoopType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Standard"/> <xsd:enumeration value="MultiInstanceSequential"/> <xsd:enumeration value="MultiInstanceParallel"/> </xsd:restriction> </xsd:simpleType>" |
| Comments |
| Comment by Stephen White [ 09/Apr/10 03:03 PM ] |
| The attached file shows the mark-ups of the proposed changes. |
| Comment by Reiner Hille-Doering [ 12/Apr/10 03:38 AM ] |
|
Hi Stephen,
I think there is still an issue with the schema in table 12.11: The tChoreographyActivity now contains an attribute "loopType" of type "tChoreographyLoopType". The other new type "tChoreographyLoopCharacteristics" is not used. But in the documentation you mention that choreography activities have a loopCharacteristics and not a loop type. Anyway, as the only relevant information of the tChoreographyLoopCharacteristics is the loopType, it might be an option to skip tChoreographyLoopCharacteristics completely. Reiner. |
| Comment by Stephen White [ 12/Apr/10 01:52 PM ] |
| The meaning of the Multi-Instance Marker rotation may change because of Issue 581 |
| Comment by Stephen White [ 12/Apr/10 01:54 PM ] |
|
Reiner,
I like the idea of simplifying the proposal and just use tChoreographyLoopType. I'll update the proposal. |
| Comment by Stephen White [ 12/Apr/10 03:27 PM ] |
| The proposal was updated on 2010-04-12 |
| Comment by Reiner Hille-Doering [ 14/Apr/10 03:50 AM ] |
| Thanks. Looks good. Could you also update the attached Word (or is also OK to see the result later during the editing process). |
| Comment by Stephen White [ 04/May/10 05:26 PM ] |
| Updated Proposal |
[BPMNFTF-566] [OMG 15137] Figure 12-21, Sub-process marker missing
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 12 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 324 Title: Figure 12-21, Sub-process marker missing Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The Figure 12-21 shows a Choreography Sub-Process. However the + marker is missing ##Proposed Resolution: Fixed Add the + marker to Figure 12.21 |
[BPMNFTF-565] [OMG 15133] Mismatch in DataAssociation definition between spec and XSD
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
Name: Suzette Samoojh
Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 2009-08-14 Page: 200 Title: Mismatch in DataAssociation definition between spec and XSD Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: tDataAssociation in the BPMN XSD does not match how it is defined in the spec or UML metamodel. Specifically, in the spec and MM, the DataAssociation has source and target associations. In the XSD, those are not on tDataAssocation, but rather on the subclasses. ##Proposed Resolution: Duplicate This issue is a duplicate of OMG Issue 14718 |
[BPMNFTF-560] [Interactions] The tethered message icons shall be restricted to choreography tasks
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Ivana Trickovic | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
The tethered message icons shall be restricted to choreography tasks. Keep notation shown on figure 8.32 and remove notation shown on figures 8.33, and 8.30 (in initial Beta 1).
##Proposed Resolution: Fixed The tethered messages are not allowed for sub-choreographies. 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 |
| Comments |
| Comment by Denis Gagne [ 08/Apr/10 10:48 PM ] |
|
8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator"
8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 ##Proposed Resolution: Resolved |
[BPMNFTF-559] [Diagram Interchange] Message icon and its usage throughout the spec
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
The proposal is that rather than having a Message payload depicted by an Envelop associated to a Participant band via an Association link, we will use a tethered message icon decorator.
This tethered message icon will be treated as an optional, visual-only decorator for Participant bands in Choreography tasks only. Sub Choreographies will not be able to show such decorator only choreography tasks. For message flows, we will only interchange message icons that appear on the message flow. These will be treated similarly i.e. a visual-only decorator of message flows. Message icons will no longer be associated to Activities or Events This simplified approach, will mostly not change user visual features, but make interchange of the message payload depiction possible with simple edits to the specs. Section 8.3.13 Message: Will have to be revised to address this. Among changes: remove figure 8.30, remove figure 8.33 |
[BPMNFTF-557] [OMG 15122] Receive Task is not mentioned as an instantiating element
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tammo van Lessen | Assigned To: | Tammo van Lessen |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Tammo van Lessen Company: Intalio mailFrom: tammo@intalio.com Notification: Yes Specification: Business Process Model and Notation Section: 14.1 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 Draft 1 RevisionDate: Feb 2010 Page: 139, 390 Title: Receive Task is not mentioned as an instantiating element Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: In 14.1, process instantiation is described. The possibilities described there are message start events and an event based gateway with out incoming sequence flow. However, on page 139, the receive task is described to be capable to instantiate process instance as well. Also the metamodel describes the "instantiate" attribute for that task. I suggest to add a paragraph to 14.1 that describes the instantiating behavior of a receive task. In addition, is it intentional that in "In order for the Task to Instantiate the Process it must meet one of the following conditions" on p139, "Instantiate" is written with a capital I? ##Proposed Resolution: Duplicate The resolution for Issue 14799 ( |
| Comments |
| Comment by Tammo van Lessen [ 18/Mar/10 07:28 AM ] |
| proposalScheduledForBallot11 |
| Comment by Tammo van Lessen [ 07/Apr/10 11:53 AM ] |
|
This issue has been solved by the proposal added to Summary of changes: - No start event allowed before instantiating Receive Task or Event Gateway (i.e. no incoming sequence flow allowed). - New stencil for Receive Task with instantiate=true (Envelope looks like a msg start event) - 14.1 mentions the Receive Task as possible way to instantiate a process model. |
| Comment by Tammo van Lessen [ 07/Apr/10 11:53 AM ] |
| New proposed resolution |
[BPMNFTF-556] [OMG 15121] Rethink implementation attribute in Send/Receive/Service Tasks
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Tammo van Lessen | Assigned To: | Tammo van Lessen |
| Resolution: | Unresolved | Votes: | 0 |
| File Attachments: |
BPMNFTF-286+556-Semantic.xsd
BPMNFTF-556-Semantic.xsd.diff
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Tammo van Lessen Company: Intalio mailFrom: tammo@intalio.com Notification: Yes Specification: Business Process Model and Notation Section: 10.2.3, 10.4.5 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 Draft 1 RevisionDate: Feb 2010 Page: 135ff, 249 Title: Rethink implementation attribute in Send/Receive/Service Tasks Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol. While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why: - Receive Task has an implementation attribute, a message event has not. - A Receive Task and a subsequent Send Task that deal with messages defined within the same operation may have different values for the implementation attribute. This is however probably not intended. My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739 As an alternative, MessageEventDefinition would need such an attribute as well. |
| Comments |
| Comment by Tammo van Lessen [ 11/Mar/10 09:53 AM ] |
|
Linked to |
| Comment by Tammo van Lessen [ 11/Mar/10 10:14 AM ] |
|
Rethinking resulted in leaving the implementation attribute as it is, since it can be useful in the non-executable models, even on send/receive/service tasks without even thinking about interfaces or operations.
However, for consistency reasons, MessageEventDefinition needs an implementation attribute. Proposal (talking about beta 1 internal draft 1 where - Update figure 10.87 (p249): Add an "implementation : String" attribute to MessageEventDefinition - Update table 10.92 (p249): Add a row for a new attribute. col 1: 'implementation : String = "##WebService"'. col 2: 'This attribute specifies the technology that will be used to receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol. A Web service is the default technology.' - Update the XML snippet table 10.109 (p263): <xsd:element name="messageEventDefinition" type="tMessageEventDefinition" substitutionGroup="eventDefinition"/> <xsd:complexType name="tMessageEventDefinition"> <xsd:complexContent> <xsd:extension base="tEventDefinition"> <xsd:sequence> <xsd:element name="operationRef" type="xsd:QName" minOccurs="0" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="messageRef" type="xsd:QName" /> <xsd:attribute name="implementation" type="tImplementation"></xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comment by Tammo van Lessen [ 11/Mar/10 10:16 AM ] |
|
Attaching changed schema ( |
| Comment by Tammo van Lessen [ 11/Mar/10 10:16 AM ] |
| New proposed resolution |
| Comment by Suzette Samoojh (IBM) [ 11/Mar/10 11:00 AM ] |
|
Tammo,
> it can be useful in the non-executable models Why would someone specify an implementation technology/protocol in a model that is not intended to be executed? I'd think the opposite would be the case ... this attribute would not be used in non-executable models. |
| Comment by Tammo van Lessen [ 18/Mar/10 07:14 AM ] |
|
As per yesterday's sub-team call, we agreed on deferring this issue as there is no urgent need to fix this minor inconsistency.
Proposed resolution: Defer. |
| Comment by Tammo van Lessen [ 18/Mar/10 07:14 AM ] |
| New proposed resolution |
| Comment by Tammo van Lessen [ 18/Mar/10 07:24 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 05/Apr/10 12:12 AM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:26 AM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-555] [OMG 15119] Merge Collaboration and Choreography in Metamodel
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 9, 12 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 age: 121, 325 Title: Merge Collaboration and Choreography in Metamodel Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Collaborations and Choreographies have a large degree of overlap in underlying capabilities--basically being a collection of Participants and Message Flow. Choreography only adds the sequencing of the Message Flow. It would be useful to be able to take the same interaction model and display it as either a Collaboration or a Choreography. The definition of those views would determine what should be displayed and how they are displayed.A merger of the two diagrams in the metamodel would greatly simplify the implementation, add flexibility, and improve BPMN support of other specifications, such as SoaML. ##Proposed Resolution: Duplicate The resolution of issue 14654 provides the resolution for this issue. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:20 PM ] |
| New Proposed Resolution |
[BPMNFTF-554] [OMG 15115] Rename "Call" Elements
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| File Attachments: |
Diagrams for Issue 554.doc
|
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 11, 12 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 301, 325 Title: Rename "Call" Elements Nature: Clarification Severity: Significant Description: The names Call Conversation and Call Choreography are confusing and incorrect. Conversations and Choreographies are not elements that can be "called." Also the Call Activity may be technically correct, it is a term not oriented for business modelers. It would be best to change the terminology for all elements that "call." |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 04/Mar/10 04:06 PM ] |
|
I think we have two cases:
- CallConversation and CallChoreography: These are not "calling". Rather they are "reusing". So, the term "call" is not semantically correct. This I agree with. Changing the name will reduce confusion amongst tool vendors as to what these things do. - CallActivity: It sounds like the real concern here is that the term "call" is not oriented to business modelers. I'm not very worried about this, because I don't see that business users necessarily need to ever see that term. Tools typically just show the global element that is being called. So, if Process A has a CallActivity that calls Process B, then what the user actually sees is Process A with a node inside of it for Process B. There's not necessarily a need for the tool to call that node out as a "Call Activity" or for the user to be exposed to the term. So from my perspective, CallActivity is a metamodel element, and hence a technical term is acceptable. If someone thinks of a replacement term that still makes sense and is also business user friendly, then great. If not, is not a real issue in my mind. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:57 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 03:47 PM ] |
|
Suzette,
As I mentioned on the call, metaclass names will appear in trainings and books as the names of BPMN concepts, whether in process or interactions, so I think it's important to have modeler-friendly ones. "Call" wasn't in BPMN 1, so it won't be missed if we change it now. The hard part is thinking of a better name. Conrad |
| Comment by Conrad Bock (NIST) [ 07/Apr/10 10:05 AM ] |
|
Some possibilities:
(Re)UseActivity (Re)UseConversation (Re)UseChoreographyActivity IncludeActivity IncludeConversation IncludeChoreographyActivity ReferenceActivity ReferenceConversation ReferenceChoreographyActivity DoActivity DoConversation DoChoreographyActivity |
| Comment by Reiner Hille-Doering [ 16/Apr/10 10:12 AM ] |
|
Counterproposal
##Proposed Resolution: Close no change Reason: - The change will cause a lot of instability in the spec as it touches so much. - As the CallActivity in Orchestration keeps the term "Call" the spec becomes inconsistent. - Even if "Call" is a technical term, it seems to be accepted by the BPMN community at least for the Orchestration case. Why should it be inaceptable in the Choreagraphy area? - "Use" is a very unspecific and frequently used term that makes is difficult to explain the meaning of the C-Activites in sentences like "Use a UseConversation actity to reference conversations that are used". - Even if the spec is not final, the community starts using the terms from the Beta. These people will be confused by such significant term change. Reiner. |
| Comment by Denis Gagne [ 16/Apr/10 10:48 AM ] |
| I support Reiner's counter proposal of Close no Change |
| Comment by Conrad Bock (NIST) [ 19/Apr/10 08:37 AM ] |
|
Reiner,
- The change will cause a lot of instability in the spec as it touches so much. It is just a global replace, it doesn't cause any instability - As the CallActivity in Orchestration keeps the term "Call" the spec becomes inconsistent. Perhaps, but that was the choice of the process modelers. "Call" at least implies some orchestration control, which you don't have in interactions. - Even if "Call" is a technical term, it seems to be accepted by the BPMN community at least for the Orchestration case. Why should it be inaceptable in the Choreagraphy area? Because "Call" means the calling process is in control of invoking the called one. There is no meaning like this in interactions. - "Use" is a very unspecific and frequently used term that makes is difficult to explain the meaning of the C-Activites in sentences like "Use a UseConversation actity to reference conversations that are used". I'd say that makes it easy to remember. - Even if the spec is not final, the community starts using the terms from the Beta. These people will be confused by such significant term change. Perhaps, but the purpose of finalization is to correct problems, some of which are in terminology. Conrad |
[BPMNFTF-553] [OMG 15103] Allow referencing scripts instead of enfocing inline specification
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank Leymann | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMN Script Invocation.docx
|
| Description |
|
##Source: IBM (Frank Leymann Leymann@iaas.uni-stuttgart.de)
Section: 10.2.3 FormalNumber: BPMN 2.0 Version: BPMN 2.0 Beta 09-08-14 RevisionDate: August 2009 Page: 142 & 143 Title: Allow referencing scripts instead of enfocing inline specification Nature: Enhancement Severity: Significant Description: Use Case: When using BPMN 2.0 in systems management environments many tasks will be implemented as scripts. Especially, a huge amount of scripts already exist in these environments and BPMN 2.0 should support an easy and straightforward way to allow making use of them as script activity implementations. Issue: Scripts to be performed must be copied to the already defined @script attribute to make it inline to the script task. In practice, this is not only redundant but also introduces a lot of potential consistency problems because the proper script might be subject to change; in that case, all copies in all script tasks must be found and adapted accordingly. Prososed resolution: Add a new attribute @scriptRef (of type URI or QName) to the scriptTask element. This allows to point to the script to be executed. Minor comments: There is no need to introduce the script separately as an operation of some (artificial) interface. This should be clarified. The script task refers to a NONE task which has been renamed into Abstract Task: needs to be fixed. An associated document (BPMN Script Invocation.DOCX) with more background has been sent to Tammo van Lessen ##Proposed Resolution: Closed, No Change The functionality proposed is provided by other means. |
| Comments |
| Comment by Tammo van Lessen [ 02/Mar/10 01:28 PM ] |
| Attaching Frank's document. |
| Comment by Suzette Samoojh (IBM) [ 03/Mar/10 09:09 AM ] |
| Couldn't the body of the script task consist of a call out to the external script? I don't think that option is ruled out by the current approach. The body would also need to extract the necessary data from the process/task and pass on to the script (possibly massaging it in the process) and also the reverse. |
| Comment by Tammo van Lessen [ 03/Mar/10 09:48 AM ] |
|
Susette, that would however require that a) the script language necessarily needs to provide means to call other scripts and b) actually two scripts are needed (one inline script to call the external script and the external script it self). I think the benefit of a scriptRef URI would be that scripts can be completely externalized and maintained independently of the process model.
Regarding data extraction. It is completely undefined yet how arbitrary script languages can access process data. I think that should remain out of scope of the spec, however it doesn't make a difference whether the script it inline or externalized. |
| Comment by Suzette Samoojh (IBM) [ 03/Mar/10 05:16 PM ] |
|
Thanks Tammo. I wasn't ruling out the proposal (a scriptRef URI). Just really pointing out that the spec doesn't require you to copy existing (potentially) large scripts into the body of the script task. Certainly a scriptRef attribute has advantages, as you've pointed out.
I'm not sure I understand how data extraction would be accomplished. The use case, as I understand, is that there are existing scripts already written. These scripts won't already have access to the process data, if they pre-existed the process. So I had assumed the script task itself would be the bridge ... it would do the data extraction and make it available in whatever form the external script was written to expect. Otherwise, you'd have to update all of the scripts to directly access the process context, which reduces the likelihood of script reuse. |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 03:13 PM ] |
|
I agree with Suzette, for several reasons:
1) the script code inside the ScriptTask would only consist of grabbing the data from the data inputs, invoke the external script, and put the results in the data outputs. 2) I don't see a need to introduce another indirection at this level (BPMN) when the scripting languages will surely provide some way of doing it. 3) I agree with last comment from Suzette about reusability of BPMN scripts, I do believe the ScriptTask code will most of the time be specific to the Task itself. So I propose to close with no change. I think this feature is not required. |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 03:14 PM ] |
| New Proposed Resolution |
[BPMNFTF-552] [OMG 15105] XML Schema is not strict enough
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Reiner Hille-Doering | Assigned To: | Reiner Hille-Doering |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
16_exchange_reiner.doc
16_exchange_reiner.doc
|
| Description |
|
##Source: SAP (Reiner Hille-Doering reiner.hille-doering@sap.com)
******************************************************************************* Name: Reiner Hille-Doering Company: SAP mailFrom: reiner.hille-doering@sap.com Notification: No Specification: BPMN 2.0 Section: XML Schema FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 1 Title: XML Schema is not strict enough Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: The XML Schemas BPMN20.xsd and Semantic.xsd define lots of global elements. This allows the elements to be used as XML file root. I don't think that this is intended: BPMN 2.0 files should be always rooted with "bpmn:definitions", and only a few elements are allowed as sub elements (including imports, diagrams and all root elements). The current design would e.g. make a file be a valid BPMN 2.0 file which consists of a single activity only. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 03/Mar/10 05:29 PM ] |
|
Reiner, are you requesting that the BPMN XSD not make use of global elements? That style of XSD is fairly prevalent ... you'll see such global elements in many standard XSDs. It is true that as a result you could create a BPMN XML which is schema valid but not BPMN valid. But global elements enable some very valuable capability (element refs, substitution groups, etc), significantly adding to the readability and consumability of the XSD. That's why they're so popular despite this one drawback.
|
| Comment by Reiner Hille-Doering [ 15/Mar/10 07:56 AM ] |
|
Hi Suzette,
after looking carefully into the schema I also understood that you use havily substituation groups as way to express the polymorhism in the metamodel. I personally would have prefered to use an appoach that avoids substitution groups and thus these unneccesary global elements. E.g in defintions instead <bpmn:definitions> <bpmn:process> ... </bpmn:process> <bpmn:collaboration> ... </bpmn:collaboration> </bpmn:definitions> this one: <bpmn:definitions> <bpmn:rootElement xsi:type="process"> ... </bpmn:rootElement xsi:type="collaboration"> <bpmn:rootElement> ... </bpmn:rootElement> </bpmn:definitions> I assume that many consider the first version "more pretty" and thus accepted the needed global elements. Anyway - it is unrealistic to change something. I would just consider to make absolutely clear in the text that a BPMN file must be "rooted" with a "defintions" element. Regards, Reiner. |
| Comment by Reiner Hille-Doering [ 22/Mar/10 07:30 AM ] |
|
proposalScheduledForBallot11
|
| Comment by Reiner Hille-Doering [ 26/Mar/10 11:17 AM ] |
| Proposed changes in Chaper 16. |
| Comment by Suzette Samoojh (IBM) [ 31/Mar/10 12:05 PM ] |
|
Reiner,
I'd suggest we not introduce new concepts (even implied ones), but rather document only what's already there. - You state that "One BPMN model consists of one or more files". I'm not sure what you consider to be "One BPMN model" ... is a process that references other processes considered one model or is it multiple models. Either are valid. So I'd not set expectations that there is a formal/understood meaning to "One BPMN model" that is represented in multiple files. - The concept of a "main" file is new. - Why specifically call out xsd or wsdl files? BPMN supports import of any kind of file (for example, xsd may be our default type system, but something else could be substituted). So I'd generalize this to state somethink like: BPMN files can import non-BPMN files (such as XSDs and WSDLs). - Why describe the partitioning of data, diagrams, etc into distinct files? The file partitioning is often based on a multiple of reasons. Not sure I see the reason for this statement. |
| Comment by Reiner Hille-Doering [ 08/Apr/10 10:13 AM ] |
|
Hi Suzette,
1: Do you have a better term? Fact is that we need to somehow explain that there is a kind of "package" of belonging files that need to import each other so that all ref-ids can be resolved. Else readers wont understand the "import" mechanism nor are able to understand how QNames are resolved. If there is already a good name for the "bundle" or "package" concept, I will for sure use it in the text. 2. Maybe, but how should a tool know from what file to start to come to a complete list of files that are needed? All files should build a cycle-free directed graph and for this you should be able to find a root node. This is exactly what I mean with "main file". Doesn't it make sense? 3. Ok, I will do so. 4. Ok, I can skip the sentence. |
| Comment by Suzette Samoojh (IBM) [ 08/Apr/10 03:05 PM ] |
|
I took a recent look at sections 8.1.1 and 8.1.2 and really like the wording there. It's nice and neutral. I don't think it's necessary to add too much additional text. And I would duplicate as little as possible.
I don't agree about cycle-free graphs. There are no limitations on circular references. When building such a graph, you would identify a 'starting point', from which you walk the graph. It may or may not be a 'root' of the graph. So, I'd suggest we keep it very simple and focus on documenting only what we have to, without introducing new concepts or restrictions at this time. Something like: When interchanging BPMN models via XML files, the BPMN content is rooted by a <bpmn:definitions> element. If there is BPMN content in other files that must be referenced, the <bpmn:import> is used to do so. To me, this is sufficient. |
| Comment by Reiner Hille-Doering [ 09/Apr/10 06:14 AM ] |
|
Hi Suzette,
I have tried to incorporate your suggestions without loosing the basic idea to guide tool vendors better in how they should create or read files. Here is my proposal: "Document Structure A domain-specific set of model elements is interchanged in one or more BPMN files. The root element of each file MUST be <bpmn:definitions>. The set of files must be self-contained, i.e. all definitions that are used in a file MUST be imported directly or indirectly using the <bpmn:import> element. Each file must declare a "targetNamespace" which MAY differ between multiple files of one model. BPMN files MAY import non-BPMN files (such as XSDs and WSDLs) if the contained elements use external definitions. " If you don't like the proposal, could you be so kind and post an alternative? Thanks, Reiner. |
| Comment by Reiner Hille-Doering [ 12/Apr/10 11:00 AM ] |
|
##Proposed Resolution: Fixed
Include the following text to chapter 16.2. For details see attachment (use newer version). Document Structure A domain-specific set of model elements is interchanged in one or more BPMN files. The root element of each file MUST be <bpmn:definitions>. The set of files must be self-contained, i.e. all definitions that are used in a file MUST be imported directly or indirectly using the <bpmn:import> element. Each file must declare a "targetNamespace" which MAY differ between multiple files of one model. BPMN files MAY import non-BPMN files (such as XSDs and WSDLs) if the contained elements use external definitions. Example: main.bpmn <?xml version="1.0" encoding="UTF-8"?> <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0" targetNamespace="sample1.main" xmlns:main="sample1.main" xmlns:s1="sample1.semantic1"> <bpmn:import location="semantic1.bpmn" namespace="sample1.semantic1" importType="http://schema.omg.org/spec/BPMN/2.0" /> <bpmn:import location="diagram1.bpmn" namespace="sample1.diagram1" importType="http://www.omg.org/spec/BPMNDI/1.0.0" /> <bpmn:collaboration> <bpmn:participant processRef="s1:process1" id="collaboration1"></bpmn:participant> </bpmn:collaboration> </bpmn:definitions> semantic1.bpmn <?xml version="1.0" encoding="UTF-8"?> <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0" targetNamespace="sample1.semantic1" xmlns:s1="sample1.semantic1"> <bpmn:process id="process1"> <!-- content here --> </bpmn:process> </bpmn:definitions> diagram1.bpmn <?xml version="1.0" encoding="UTF-8"?> <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0" targetNamespace="sample1.diagram1" xmlns:bpmndi="http://www.omg.org/spec/BPMNDI/1.0.0" xmlns:d1="sample1.diagram1" xmlns:s1="sample1.semantic1" xmlns:main="sample1.main"> <bpmndi:BPMNDiagram scale="0.0" unit="Pixel"> <bpmndi:BPMNPlane element="main:collaboration1"> </bpmndi:BPMNPlane> </bpmndi:BPMNDiagram> </bpmn:definitions> |
| Comment by Pete Rivett [ 13/Apr/10 12:10 PM ] |
|
The proposal is over-constraining by referring to 'files' - so long as the bpmn:import location is de-referenceable it should not matter whether it is stored in a file or some other sort of resource realized on demand.
BTW the spec should clarify this in the description of the 'location' attribute of bpmn:import. This should arguably be a URL not a String. I share Suzette's concerns about the use of the term 'one model' (which still appears in line 2) - how is this scoped? By making 'targetNamespace' required does this invalidate Table 8.16 which declares it as ""? The proposal needs to update section 16.2 to mandate that each namespace prefix used in a Qname MUST correspond to a namespace referenced by a bpmn:import element. Finally I'm not comfortable that the proposal seems to address quite a different concern than expressed in the original issue which was to do with global elements - indeed I only stumbled across it by accident. |
| Comment by Reiner Hille-Doering [ 14/Apr/10 03:47 AM ] |
|
Hi Pete,
fiirst of all: What I try here is to guide the user to use the correct file structure, because the schema doesn't do the job: As there are many global elements, there is no hint that "defintions" must be the root. As the schema cannot be changed (because all the global elements and substutution groups are used to as a way to express polymorphism) I thought it is a good idea to have some text. Now about your other issues: -Please provide a better term if you don't like "files". -The remaining "of one model" in the second line is more an accident. I could skip it completely. Anyway I don't understand your and Suzette's "fear" of the word "Model". This was anyway used e.g. in the heading of Section 16.1. - and I didn't change this. -Making targetNamespace non-option in Table 8.16 is something that I would not risk to decide. On the other hand not having a targetNamespace would simply not work with the QName reference logic. Maybe Suzette could comment if the metamodel/schema should be changed. - I didn't touch the "Refeferences" section so far. I was aynway assuming the "self contained", and "MUST be imported" is clear enough together with the defintion if the "import" element of the Defintions type how prefixes and namespaces are used. Anyway it valid to add such a sentence to the Reference section. Reiner. |
| Comment by Denis Gagne [ 13/May/10 09:17 AM ] |
|
Spec-Draft3-review
In the resolution, in the portion for the diagram1.bpmn file, the line: <bpmn:import location="diagram1.bpmn" namespace="sample1.diagram1" importType="http://www.omg.org/spec/BPMNDI/1.0.0" /> Should be: <bpmn:import location="diagram1.bpmn" namespace="sample1.diagram1" importType="http://schema.omg.org/spec/BPMN/2.0" /> As althought the file only contain a diagram, this diagram is in a BPMN 2.0 file and as such the import should be BPMN 2.0. Futhermore, the BPMNDI import type is not specified as a mandatory import type to support on page 44 |
| Comment by Reiner Hille-Doering [ 14/May/10 04:56 AM ] |
| Denis, you are perfectly right. I'm anyway not sure if the examples there are still correct using the final schemas, especially considering the final namespace IDs. |
| Comment by Ivana Trickovic [ 17/May/10 03:38 PM ] |
|
As per the meeting of May 17th: A few changes to be made. See issue |
| Comment by Stephen White [ 19/May/10 09:16 PM ] |
| Done |
[BPMNFTF-551] [OMG 15104] How to reference particular instances of Data Objects that are Collections
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank Leymann | Assigned To: | Unassigned |
| Resolution: | No Action | Votes: | 0 |
| File Attachments: |
BPMN Script Invocation.docx
|
| Description |
|
##Source: IBM (Frank Leymann Leymann@iaas.uni-stuttgart.de)
******************************************************************************* Name: Frank Leymann Company: IBM mailFrom: Leymann@iaas.uni-stuttgart.de Notification: Yes Specification: BPMN 2.0 Section: 10.3.1 Data Modelling FormalNumber: BPMN 2.0 Version: BPMN 2.0 Beta 09-08-14 RevisionDate: August 2009 Page: 184ff Title: How to reference particular instances of Data Objects that are Collections Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: How can one address (in an <assignment>, for example) a particular instance of a multi-instance data object, i.e. a data object with attribute isCollection value set to "true"? It is unclear why the ioSpecification must be defined with isCollection=true to result in multi-instance execution of the task. Why isn't it sufficient to refer (via the dataInputAssociation/sourceRef element) to a multi-instance data object to trigger multi-instance exection of the task. Is the attribute isCollection needed as attribute of dataInput and dataOutput at all? [Multi Instance Tasks controlled by loopDataInput (Section 10.2.8)] I assume that defining a data object with isCollection=false based on an itemDefinition with isCollection=true is not allowed, correct? But the reverse is allowed as shown in the document. The question is why supporting isCollection as attribute of an item definition at all; supporting isCollection with elements *using* the item definition would suffice. [Item Definition as multi-instance (Section 8.3.12)] A corresponding document (BPMN Script invocation.DOCX) with more background has been sent to Tammo van Lessen. ##Proposed Resolution: Closed, No Change Section 8.3.12 properly describes the behaviour in the case the data object is a collection. |
| Comments |
| Comment by Tammo van Lessen [ 02/Mar/10 01:28 PM ] |
| attaching Frank's document. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:21 PM ] |
|
As per March F2F Meeting:
The specification (Beta 1) says the following: "In cases where the data structure represents a collection, the multiplicity can be projected into the attribute isCollection. If this attribute is set to "true," but the actual type is not a collection type, the model is considered as invalid. BPMN compliant tools might support an automatic check for these inconsistencies and report this as an error. The default value for this element is "false." So we can close this issue as there is no problem. |
[BPMNFTF-550] [OMG 15102] For DI: All graphical elements should have a Semantic Counterpart
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange, Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
******************************************************************************* Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 11 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 272 Title: For DI: All graphical elements should have a Semantic Counterpart Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Most graphical elements have a semantic counterpart. It should be a design principle that all elements follow this pattern. One exception is the Communication Link, which is merely an association between two Elements. The Communication Link, and any other similar DI situations, should be given its own semantic element. ##Proposed Resolution: Duplicate The resolution of issue 15068 will resolve this issue |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 04/Mar/10 04:13 PM ] |
|
We should probably rephrase this requirement and/or title.
It's not that all graphical elements should have a semantic counterpart, or that we're doing this for DI. Such a principle could result in a semantic model that is cluttered with purely visual features. Rather, the principle is that anything with significant semantic meaning or purpose should have a first class semantic element. The end result will be the same because anything that is important enough to to notate (i.e. have a graphical element) typically has significant semantic meaning. This would just be a more correct description of the principle that we want to apply. |
| Comment by Stephen White [ 18/Mar/10 08:25 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 30/Mar/10 12:44 PM ] |
| New Proposed Resolution |
[BPMNFTF-549] [OMG 15101] Integrate temporal and token semantics
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | General, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Fred Cummins | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Fred Cummins Company: HP mailFrom: fred.cummins@hp.com Notification: Yes Specification: BPMN Section: 7 and 8 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: August, 2009 Page: 13-110 where applicable Title: Integrate temporal and token semantics Nature: Clarification Severity: Significant Test: 3qw8 B1: Report Issue Description: BPMN uses temporal semantics currently in process abstraction, and token flow in process execution. It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics. |
| Comments |
| Comment by Conrad Bock (NIST) [ 15/Mar/10 09:16 AM ] |
|
---------- New Proposed Resolution ----------- 2010-03-15 ----------------------------
-------------------- Proposal ----------- 2010-03-15 --------------------------------- ##Proposed Resolution: Defer This can be addressed in an RTF by clarifying the relationship between temporal and token semantics. |
[BPMNFTF-548] [OMG 15095] Review the use of RFC2119 keywords
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivana Trickovic | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Ivana Trickovic Company: SAP AG mailFrom: ivana.trickovic@sap.com Notification: No Specification: BPMN 2.0 Section: all normative sections FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: August 2009 Page: all normative sections Title: Review the use of RFC2119 keywords Nature: Clarification Severity: Significant test: 3qw8 1: Report Issue Description: Description: Ensure consistent use of RFC-2119 keywords ("MUST," "MUST NOT," "REQUIRED," "SHALL," "MUST NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL"). |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:32 AM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 12/Apr/10 04:33 PM ] |
|
-------------------- Proposal ---------- 2010-04-12 -------------------------------------
##Proposed Resolution: Fixed Make the following changes in the document (Beta 1, Aug 2009, pdf) (1) Change all *must* occurrences to *MUST* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (2) Change all *must not* occurrences to *MUST NOT* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (3) Change all *are NOT*/*is NOT* occurrences to *are not*/*is not* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (4) Change all *required* occurrences to *REQUIRED* (in sections 2-12 and 14-16, except in figure 10.121; do not change occurrences of 'required' and "required") (5) Change all *shall* occurrences to *SHALL* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (6) Change all *shall not* occurrences to *SHALL NOT* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (7) Change all *recommended* occurrences to *RECOMMENDED* (in sections 2-12 and 14-16, excluding 3.1 and 3.2) (8) In addition make the following changes - Page 19: Include "A Start Event generates a token that MUST be consumed at an End Event (which is implicit if not graphically displayed)." instead of "A Start Event generates a token that must eventually be consumed at an End Event (which may be implicit if not graphically displayed)." - Pages 131, 221, 225, 236: Include "All Message Flow MUST connect two separate Pools. They MAY connect to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT connect two objects within the same Pool." instead of "All Message Flow must connect two separate Pools. They can connect to the Pool boundary or to Flow Objects within the Pool boundary. They cannot connect two objects within the same Pool." - Page 160: Include "First, the transaction protocol needs to verify that all the Participants have successfully completed their end of the Transaction." instead of "First, the transaction protocol must verify that all the Participants have successfully completed their end of the Transaction." - Page 164: Include "The addition of Sequence Flow between the Tasks (e.g., between "Generate Graphics" and "Include Graphics in Text") creates a dependency where the performance of the first Task MUST be followed by a performance of the second Task. This does not mean that the second Task is be performed immediately, but there MUST be a performance of the second Task after the performance of the first Task." instead of "The addition of Sequence Flow between the Tasks (e.g., between "Generate Graphics" and "Include Graphics in Text") creates a dependency where the performance of the first Task must be followed by a performance of the second Task. This does not mean that the second Task must be performed immediately, but there must be a performance of the second Task after the performance of the first Task." - Page 197: Include "The implementation of the element where the OutputSet is defined determines the OutputSet that will be produced." instead of "The implementation of the element where the OutputSet is defined must determine the OutputSet that will be produced." - Page 310: Include "However, if there are more than two (2) Participants, then the modeler needs to be careful to sequence the Choreography Activities in such a way that the Participants know when they are responsible for initiating the interactions." instead of "However, if there are more than two (2) Participants, then the modeler must be careful to sequence the Choreography Activities in such a way that the Participants know when they are responsible for initiating the nteractions." - Page 313: Include "The data referenced in the conditions need to be visible to two (2) or more Participants in the Choreography" instead of "The data referenced in the conditions must be visible to two (2) or more Participants in the Choreography" - Page 328: Include "The data used to define the loop conditions need to be visible to all Participants" instead of "The data used to define the loop conditions must be visible to all Participants" - Page 328: Include "This means that the ordering of Choreography Activities need to take into account when the Participants send or receive..." instead of "This means that the ordering of Choreography Activities must take into account when the Participants send or receive..." - Pages 335, 336: Include "The data are be visible to the Participants as it was data of a previously sent Message." instead of "The data must be visible to the Participants as it was data of a previously sent Message." - Page 2: Include "Where permitted or requested connections are specified as conditional" instead of "Where permitted or required connections are specified as conditional" - Page 3: Include "Some of these attributes are purely representational and are so marked, and some have mandated representations." instead of "Some of these attributes are purely representational and are so marked, and some have required representations." - Page 11: Include "Section 8 introduces the BPMN Core that includes basic BPMN elements needed..." instead of "Section 8 introduces the BPMN Core that includes basic BPMN elements required..." - Page 13: Include "... it is likely that business analysts need to understand multiple representations..." instead of "...it is likely that business analysts are required to understand multiple representations..." - Pages 15, 124, 126: Include "Thus, information needed for execution, such as formal condition expressions are typically not included in a non-executable Process." instead of "Thus, information required for execution, such as formal condition expressions are typically not included in a non-executable Process." - Pages 15, 126. Include "...the public Process shows to the outside world the Message Flow and the order of those Message Flow that are necessary to interact..." instead of "...the public Process shows to the outside world the Message Flow and the order of those Message Flow that are required to interact..." - Page 20: Include "There are two (2) standardized Artifacts, but modelers or modeling tools are free to add as many Artifacts as necessary." instead of "There are two (2) standardized Artifacts, but modelers or modeling tools are free to add as many Artifacts as required." - Page 51: Include "It is the intention of this specification to cover the basic elements necessary for the construction..." instead of "It is the intention of this specification to cover the basic elements required for the construction" - Page 53: Include "For example, an EventDefinition may be contained in a Process since it may be only required there." instead of "For example, an EventDefinition would be contained in a Process if it is used only there." - Page 131: Include "The following sections define how Resources can be defined..." instead of "The following sections define how required Resources can be defined..." - Page 143: Include "In many business workflows, human involvement is required to complete certain..." instead of "In many business workflows, human involvement is needed to complete certain" - Page 162: Include "The default setting is parallel and the setting of sequential is a restriction on the performance that may be needed due to shared resources." instead of "The default setting is parallel and the setting of sequential is a restriction on the performance that may be required due to shared resources." - Page 163: Include "Although there is no explicit Process structure,..." instead of "Although there is no required formal Process structure," -Page 190: Include "Activities and Processes often require data in order to execute." instead of "Activities and Processes often required data in order to execute." -Page 296: Include "For example, Order Id is necessary for in all Messages of Message Flow in Delivery Negotiation." instead of "For example, Order Id is required for in all Messages of Message Flow in Delivery Negotiation." - Page 397: Include "In practice, it would entail a special-purpose mediator which not only provides the extraction and data assignment, but also any necessary data transformation." instead of "In practice, it would entail a special-purpose mediator which not only provides the extraction and data assignment, but also any required data transformation." - Page 437: Include "Second, the activities that need to be duplicated can be removed from the main Process and placed in a derived process that is called (invoked) from all locations in the WSBPEL elements as needed." instead of "Second, the activities that need to be duplicated can be removed from the main Process and placed in a derived process that is called (invoked) from all locations in the WSBPEL elements as required." - Page 438: Include "...particularly if a WSBPEL pick is requested." instead of "...particularly if a WSBPEL pick is required" - Page 439: Include "Such "incomplete" models are ones in which all of the mandatory attributes have not yet been filled in, or the cardinality lowerbound of attributes and associations has not been satisfied." instead of "Such "incomplete" models are ones in which all of the required attributes have not yet been filled in, or the cardinality lowerbound of attributes and associations has not been satisfied." - Page 4: Include "• how the feature will be displayed • whether the feature will be displayed • whether the feature will be supported" instead of "• how the feature shall be displayed • whether the feature shall be displayed • whether the feature shall be supported" - Page 68: Include "a Conversation may additionally refer to explicitly updateable Process context data to determine whether or not a Message need to be received" instead of "a Conversation may additionally refer to explicitly updateable Process context data to determine whether or not a Message shall be received" - Page 11: Include "The following abbreviations are used throughout this document:" instead of "The following abbreviations may be used throughout this document:" - Page 14: Include "BPMN 2.0 can be mapped to more than one platform dependent" instead of "BPMN 2.0 may be mapped to more than one platform dependent" - Page 15: Include "Collaborations, which can include Processes and/or Choreographies" instead of "Collaborations, which may include Processes and/or Choreographies" - Page 16: Include "The Messages associated with the Message Flow can also be shown." instead of "The Messages associated with the Message Flow may also be shown." |
| Comment by Falko Menge [ 30/Apr/10 11:39 AM ] |
|
On Pages 335, 336 it should be
"The data are visible..." instead of "The data are be visible..." |
| Comment by Falko Menge [ 03/May/10 12:04 PM ] |
| As per FTF call on 2010-05-03, we decided to address the previous comment on this issue as part of BPMNFTF-312. |
[BPMNFTF-547] [OMG 15093] Choreography should be a Sub-Class of Collaboration
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 9 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 111 Title: Choreography should be a Sub-Class of Collaboration Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: The work on the merger between Conversation and Collaboration is making clear that Choreography is completely overlaps with (the merged) Collaboration, but extends its capabilities. Thus, it would make sense to make Choreography a sub-class of Collaboration. This would simplify the metamodel and make the Interaction Specification class no longer necessary ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:31 PM ] |
| New Proposed Resolution |
[BPMNFTF-546] [OMG 15091] Additional participants in called/subconversation
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Dale Moberg | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Dale Moberg Company: Axway mailFrom: dmoberg@axway.com Notification: Yes Specification: BPMN 2 Section: Conversation FormalNumber: dtc/09-08-14 Version: RevisionDate: Page: Title: Additional participants in called/subconversation. Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Called and subconversations should be able to have more participants than the calling/outer conversation. The additional participants would not be associated with any in the calling/outer conversation. ##Proposed Resolution: Close, No Change Called conversations can have additional participants. Subconversations cannot, they are owned by the containing conversation, but diagrams can show participants only in the subconversation, if desired. |
| Comments |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 09:56 AM ] |
| proposalScheduledForBallot10 |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 08:53 AM ] |
| New Proposed Resolution: Close, No Change |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 08:54 AM ] |
|
-----------Proposal----------------03/26/2010---------------------------
##Proposed Resolution: Close, No Change Called conversations can have additional participants. Subconversations cannot, they are owned by the containing conversation, but diagrams can show participants only in the subconversation, if desired. |
[BPMNFTF-545] [OMG 15087] Contradictory/redundant handing of data and subprocesses
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 216, 221-223 Title: Contradictory/redundant handing of data and subprocesses Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Consider a process with a Data Object and a Subprocess. The subprocess has an activity. Can you draw a data association from the data object (in the process) directly to the activity (in the subprocess). - The introduction of Data Inputs/Outputs for subprocesses implies you should always go through the Data Inputs/Outputs. That is, you must draw the data association from the Data Object to the subprocess Data Input, and then draw another data association from the subprocess Data Input to the Activity inside the subprocess. - But then page 216 states that the data object is 'visible' to the subprocess and the activity inside the subprocess, which implies the activity can access it directly without necessarily going through the subprocess data input. So, two different means of doing the same thing, with likely different tools assuming/supporting one or the other or both. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:20 PM ] |
|
As per March F2F Meeting:
- Agree this issues should be further discussed. We need to assign the issue to someone. |
| Comment by Suzette Samoojh (IBM) [ 23/Mar/10 05:26 PM ] |
| proposalScheduledForBallot11 |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 05:02 PM ] |
|
Looks like this will be covered by ------------------------------------------------------------------------------ ##Proposed Resolution: Duplicate This issue has the same resolution as OMG 14817 ( |
[BPMNFTF-544] [OMG 15086] Add Attribute Table for Global Task
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 167 Title: Add Attribute Table for Global Task Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: A Global Task has a performers attribute. This should be listed in a table in Section 10.2.7 ##Proposed Resolution: Duplicate The resolution of this issue is included as part of |
[BPMNFTF-543] [OMG 15085] Incorrect attribute name used for Start Event definition
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 221 Title: Incorrect attribute name used for Start Event definition Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Bullet items for Start Event Message Flow Connections refers to the "Trigger" attribute of the Start Event. The name of this attribute was changed to "eventDefinitionRefs." These items, and other similar uses of the word Trigger, should be corrected. ##Proposed Resolution: Fixed The statements of those bullets is actually wrong, the trigger attribute do not have a value of "Message" or "Multiple", they are EventDefinition elements. Also they do not add any value since the connection rules are properly described in Section 7.5.2 Mesage Flow Connection Rules So the proposed fix is to remove these 2 bullets: • The Trigger attribute of the Start Event MUST be set to Message or Multiple if there are any incoming Message Flow. • The Trigger attribute of the Start Event MUST be set to Multiple if there are more than one incoming Message Flow. |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 04:41 AM ] |
|
As per March F2F Meeting:
- This is an editorial issue. |
[BPMNFTF-542] [OMG 15083] No way to identify the format of Documentation and TextAnnotation connect
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: All FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: All Title: No way to identify the format of Documentation and TextAnnotation connect Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The XSD schema supports mixed-content text within Documentation or Text Annotations. This allows for formatted content (e.g. html tags for bolding or italics). The problem occurs when interchanging the XML, since a consumer of the XML has no way of telling what format was used for the text (i.e. to tell that it was html rather than plain text). Recommend adding an attribute for a mime-type. Example usages could then be "text/plain" for regular text and "text/html" for html structured text. ##Proposed Resolution: Fixed 1. Spec tables 8.6 and 8.24: Add an attribute to both Name: "textFormat: string" Description: This attribute identifies the format of the text. It must follow the mime-type format. The default is "text/plain". 2. UML metamodel: Update the UML metamodel to add the same attribute to the Documentation and TextAnnotation classes. Replace all spec figures that show the Documentation and TextAnnotation classes. 3. XSD: Add an attribute to the tDocumentation and tTextAnnotation complexTypes <xsd:attribute name="textFormat" type="xsd:string" default="text/plain"/> Update the XSD snippets in tables 8.17 and 8.29 to match. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 18/Mar/10 10:58 AM ] |
| proposalScheduledForBallot10 |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 11:24 AM ] |
|
Add a "textFormat" attribute of type "String". It must follow the mime-type format. The default is "text/plain".
-------------------------------------------------------------------------------------- Proposed resolution: Fixed 1. Spec tables 8.6 and 8.24: Add an attribute to both Name: "textFormat: string" Description: This attribute identifies the format of the text. It must follow the mime-type format. The default is "text/plain". 2. UML metamodel: Update the UML metamodel to add the same attribute to the Documentation and TextAnnotation classes. Replace all spec figures that show the Documentation and TextAnnotation classes. 3. XSD: Add an attribute to the tDocumentation and tTextAnnotation complexTypes <xsd:attribute name="textFormat" type="xsd:string" default="text/plain"/> Update the XSD snippets in tables 8.17 and 8.29 to match. |
| Comment by Pete Rivett [ 28/Apr/10 08:06 PM ] |
|
I'm a bit worried about the lack of constraint on the MIME type used - should it not at least start with "text/" to disallow the inclusion of images or even videos?
The suppoirt of different text types should also be considered as a conformance point - is it mandatory that all tools support and 'properly' render even all variations of 'text/' MIME types? |
| Comment by Suzette Samoojh (IBM) [ 29/Apr/10 12:45 PM ] |
|
Pete has a very good point. I hadn't thought of this.
It would make sense to constrain the MIME types to the "text/*" set, at a minimum. From a quick scan of that set, the ones that strike me as the most likely/useful are: text/plain, text/html, text/richtext. But there might be others that I didn't notice. I wouldn't restrict vendors from supporting types outside of that set, but if they did then I would position it as an extension point, meaning there is no guarantee that another tool will be able to properly render the text. I don't know what the process is to get this change in. I'd suggest opening another issue and tackling in the RTF, but that's solely based on where we are in the FTF project plan. If there is an easy way to do this within the FTF, I'm also open to that. |
| Comment by Suzette Samoojh (IBM) [ 03/May/10 10:50 AM ] |
|
Discussion in the FTF meeting on May 3, 2010:
- Pete has a good point. But at this time it is difficult to say what formats will be widely used. If we attempted to address this now, it would be based largely on guess-work. We need time to collect data and feedback so we can enhance the proposal further to add realistic constraints. - The FTF agreed to: - Proceed with the proposal. It is moving the spec in the right direction. - Request a new issue to enhance the spec further with constraints on the specific mime types. This would be tackled in the future, giving us more time to collect the necessary data. |
[BPMNFTF-541] [OMG 15082] Extending via inheritancy is problematic using the BPMN xsd format
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General, Schema |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Example-Extension.xsd
Sample instance.xml
Semantic-Snippet.xsd
|
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: All FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: All Title: Extending via inheritancy is problematic using the BPMN xsd format Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Extending via inheritancy is problematic using the BPMN xsd format. The presence of the 'any' element on tBaseElement creates issues if you create subclasses that reside in a non-BPMN namespace. You cannot add elements to the subclass without violating the Unique Particle Attribution (UPA) rule in XML Schema (http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/structures.html#non-ambig) |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 17/Mar/10 04:37 PM ] |
|
Proposal to introduce a wrapper for the 'any' element. This allows us to subclass without violating the UPA XSD rule.
-------------03/17/2009---------------------------------------------------------------- ##Proposed Resolution: Fixed (a) Update tBaseElement and tBaseElementWithMixedContent in the XSD (see Semantic-Snippet.xsd attached to this issue) (b) Update the XSD snippets (Table 8.17) in the spec |
| Comment by Suzette Samoojh (IBM) [ 18/Mar/10 10:57 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 11/Jun/10 11:00 AM ] |
|
spec-May24-review
[AB feedback] Feedback from Steve Cook, Microsoft: Resolution 15082 has been annotated in the spec with change bars as issue 15802. This should be corrected. |
| Comment by Ivana Trickovic [ 11/Jun/10 11:00 AM ] |
|
As per the 6/7 meeting:
-To be corrected |
[BPMNFTF-540] [OMG 15080] Data Objects should be defined with the same pattern as Data Stores and DataStoreRefs
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 183 Title: Data Objects should be defeind with the same pattern a Data Stores and DataStoreRefs Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: There can be multiple visible occurrences of the same DataObject according to the spec. But this seems to be wrong: there should be multiple occurrences of DataObjectRef, each referring to the same DataObject, as was done with DataStore and DataStoreRef |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 25/Feb/10 01:50 PM ] |
|
I don't really agree.
We do need to support multiple visualizations of the same semantic Data Object, but "visualizations" is the key word. This implies it is not a semantic issue, but rather pure visualization (i.e. something for the DI to address). Otherwise, we're inserting requirements/concepts that are purely visual into what is supposed to be a semantic model. The DataStore is a different situation. Because the DataStore exists outside of the process, we wanted something inside of the Process to indicate that the DataStore is being used or will be used. That's why the DataStoreRef was introduced. It is essentially analagous to a CallActivity, but is for DataStores instead of global activities. The same is not true of Data Objects. It already exists inside of the process. So what would then be the semantic motivation for a DataObjectRef? |
| Comment by Stephen White [ 01/Mar/10 08:46 PM ] |
| We should allow for Data Objects that exist beyond the context of a specific Process. Certainly with Case Management we will need to do this. Besides that, it would be useful to be able to pull in long-lived documents into a Process for reference or update. |
| Comment by Suzette Samoojh (IBM) [ 02/Mar/10 10:56 AM ] |
| I think that is a different issue (and not one I quite understand). If we make such a change, we can then see if it justifies creation of a DataObjectRef. For now, we need a justification that is based on the current definition of DataObjects. |
| Comment by Mariano Benitez (Oracle) [ 09/Mar/10 04:28 PM ] |
|
In the DI discussion on F2F (March 9th) we reached the conclusion we need the DataObjectRef to hold the relation with the Data State, instead of the DataObject.
We based our conclusion in the fact that there is a single DataObject definition in a process, with a given name (say "Issue"), but there are many visual instances of that single DataObject with different states (first is pending, later is approved). So there is no way to have the same data object hold that multiple information. I remember at some point we discussed that the previous case would be covered by different data objects, but this is not the general understanding of how data objects work. Even in the FTF workflow example, we have the same data object (the issue) with multiple states, and I would assume it is the same data object. We have not completed the discussion, but I just wanted to reflect the conversations today in the F2F. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:19 PM ] |
|
As per March F2F Meeting:
- Agreed that this issue should be addressed. Assigned to Mariano. |
| Comment by Conrad Bock (NIST) [ 10/Mar/10 09:15 AM ] |
|
I don't think it's necessary to have multiple visualizations of the same
data object, and might be harmful. For example, it opens the possibility that one part of a diagram is updating the same data object at the same time as another. Which value would be read in those different parts of the diagram? My impression is typical users would see these visualizations as separate "buckets" that are updated separately. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:50 PM ] |
| After the straw poll on Monday Mar 15th, I cannot commit to provide a full proposal (since I do not agree with the resolution that was agreed). |
| Comment by Ivana Trickovic [ 16/Mar/10 04:28 PM ] |
|
As per 3/15 Meeting:
Straw poll - Option 1: Have DataObject and DataObjectRef which carries the state of the DataObject. In this case we visualize the DataObjectRef - Option 2: Multiple DataObjects depicting the same information in different states. So DataObject is like "variable" and the name of the variable is <DataObject>.<State>. Multiple instances of Data Object is XSD. Straw poll goes for Option 1 (DataObjectRef with state, referring to DataObject). Results: Op1 - 6 votes; Op2 - 1 vote, Abstain - 2 votes |
| Comment by Conrad Bock (NIST) [ 17/Mar/10 11:04 AM ] |
|
A simpler way is to add an association from DataObject to itself
indicating the runtime instances filling them will be the same. Then implementations can just make separate DataObjects in the model for each data object icon, and if the user wants them to be the same as in Steve's example, add a link to other data objects that will have the same value. With DataObjectRef, creating a data object icon with a state will require instantiating two metaclasses and linking them, or adding a state might require reclassifying a data object as a data object ref. |
| Comment by Suzette Samoojh (IBM) [ 17/Mar/10 11:25 AM ] |
|
I don't find this option intuitive. Let's stick with the option the group already voted on.
On the last point ("reclassifying a data object as a data object ref"), I don't see the need. The data object icon is always backed by a Data Object Ref. Presence or absence of a state does not matter. So there would be no reclassification involved. |
| Comment by Tammo van Lessen [ 17/Mar/10 11:35 AM ] |
| I agree with Suzette. Let's stick with the voted option. |
| Comment by Conrad Bock (NIST) [ 17/Mar/10 12:07 PM ] |
|
> I don't find this option intuitive. Let's stick with the option the
> group already voted on. I didn't know the poll was going to happen so didn't have time to prepare another option. The voted object introduces an unneeded metaclass, and the execution semantics wasn't given. I don't find the DataObjectRef solution intuitive, certainly not from a user viewpoint. > On the last point ("reclassifying a data object as a data object > ref"), I don't see the need. The data object icon is always backed by > a Data Object Ref. Presence or absence of a state does not matter. So > there would be no reclassification involved. OK, so the implementation makes two objects, an Data Object Ref and a Data Object, even if there is no state, unless the user indicates to refer to an existing data object. This is more complex than just making a data object and optionally added a link to another data object for Steve's example. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:58 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:16 PM ] |
|
In Process Orchestration subteam meeting of March 24, Conrad suggested
the execution semantics of data object refs have the option to be specified per Steve's example, in paticular that the value of a data object cannot change once it has been assigned. Matthias was concerned about how identity of the value is determined. It was agreed to postpone the execution semantics of Steve's example to the RTF as a separate issue. |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 06:07 PM ] |
|
Some questions:
- Why not make DataObjectRef a subclass of ItemAwareElement. It would then inherit the dataState attribute. Also, in order for data associations to connect to/from DataObjectRef, it would have to be an ItemAwareElement. - The line "Data Object Refs have the same notation as the Data Objects they refer to". Do Data Objects still have notation? Can I create a diagram that shows Data Objects and no Data Object Refs? In my mental model, Data Objects are no longer visualized. Only Data Object Refs are. |
| Comment by Mariano Benitez (Oracle) [ 06/Apr/10 10:09 AM ] |
|
I believe that DataObjectRefs are the elements that can be visualized, not DataObjects (not anymore). Otherwise it can get complicated to figure what to show, a DataObject or a Ref...
I also agree to make DataObjectRef an ItemAwareElement, but this also modifying the places where the list of ItemAwareElements appear. So I believe the DI chapter should be reviewed, and Denis should be notified of the change. |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 10:40 AM ] |
|
Suzette, Mariano,
[Suzette] Why not make DataObjectRef a subclass of ItemAwareElement. It would then inherit the dataState attribute. Also, in order for data associations to connect to/from DataObjectRef, it would have to be an ItemAwareElement. [Mariano] I also agree to make DataObjectRef an ItemAwareElement, but this also modifying the places where the list of ItemAwareElements appear. Then the data object ref could have a different item (type) than the "reused" data object. Is that the intention? [Suzette] The line "Data Object Refs have the same notation as the Data Objects they refer to". Do Data Objects still have notation? Can I create a diagram that shows Data Objects and no Data Object Refs? In my mental model, Data Objects are no longer visualized. Only Data Object Refs are. I believe that DataObjectRefs are the elements that can be visualized, not DataObjects (not anymore). Otherwise it can get complicated to figure what to show, a DataObject or a Ref... Was trying to avoid modelers needing to call them "data object refs", or be concerned with the different between data object refs and data objects. And as Mariano says, to avoid impact on DI. We could avoid these problems by just adding an association between DataObjects indicating they have the same value at runtime for each execution of the diagram, rather than introducing a new concept. Conrad |
| Comment by Suzette Samoojh (IBM) [ 06/Apr/10 01:43 PM ] |
|
> Then the data object ref could have a different item (type) than the "reused" data object. Is that the intention?
Good point. No, that was not the intention. We could simply state that the DORef does not specify a type of its own. Rather it's type is always derived from the referenced DO. How do you see Data Associations working? Currently, they can only connect between ItemAwareElements. So that was the real motivation behind my suggestion. > Was trying to avoid modelers needing to call them "data object refs", or be concerned with the different between data object refs and data objects. And as Mariano says, to avoid impact on DI. Okay, I see. My mental model is that modelers would see 'occurences of Data Objects' in their diagram. The Data Object icon maps down to DORefs in the model, with tools managing the difference between DORefs and DOs. So modelers don't need to necessarily be exposed to the term "data object ref" or even to see it as a significantly new concept. |
| Comment by Suzette Samoojh (IBM) [ 06/Apr/10 01:44 PM ] |
|
Wrt the DI, I think Denis was promoting this direction anyways, since it helps him with the DI. See |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 02:18 PM ] |
|
Suzette,
> Good point. No, that was not the intention. We could simply state > that the DORef does not specify a type of its own. Rather it's type > is always derived from the referenced DO. Would be good if we could avoid textual constraints. > How do you see Data Associations working? Currently, they can only > connect between ItemAwareElements. So that was the real motivation > behind my suggestion. Hadn't thought of that. See below. > Okay, I see. My mental model is that modelers would see 'occurences > of Data Objects' in their diagram. The Data Object icon maps down to > DORefs in the model, with tools managing the difference between > DORefs and DOs. So modelers don't need to necessarily be exposed to > the term "data object ref" or even to see it as a significantly new > concept. > Wrt the DI, I think Denis was promoting this direction anyways, since > it helps him with the DI. See That one seems to be about showing the same abstract syntax element more than once in a diagram, rather than showing an icon for one kind of element (data objects) with a different one in the AS (data object refs). In any case, the new concept (data object refs) will need to be described in tables and diagrams in the spec, and show up in training materials derived from it. The above problems (textual constraints, DI issues, modeler confusion) seem to indicate adding a new concept is really too much trouble. The original intention of Steve's example is the runtime values of data objects are the same for some of the data objects in the model. It would be easier just to add an association between data objects that says this. Then data objects still have their own states, and can be connected by data associations. If they have incompatible types, it would just be a modeling inconsistency. Seems like a simpler way to establish "reuse" that also captures some runtime semantics. Conrad |
| Comment by Suzette Samoojh (IBM) [ 06/Apr/10 02:46 PM ] |
| Maybe I'm misunderstanding. Are you suggesting we abandon the direction in the posted proposal, in favour of another (i.e. data objects referencing other data objects)? I think several of us already voiced opinions that the data object ref direction is the one we'd support. I'd much prefer we just focus on fixing the posted proposal (e.g. address data associations). I don't think we collectively have the bandwidth to start over with a new direction and discussion. |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 03:25 PM ] |
|
Suzette,
> Maybe I'm misunderstanding. Are you suggesting we abandon the > direction in the posted proposal, in favour of another (i.e. data > objects referencing other data objects)? Yes, I'm only writing the proposal the group informally voted on. I don't agree with it, at least so far. > I think several of us already voiced opinions that the data object > ref direction is the one we'd support. Mariano and I didn't. At the F2F, it was agreed we'd reach consensus. A straw poll was taken at the next telecon without prior announcement. I wasn't prepared to answer at the time, but the problems with the proposal are pretty clear when it's worked through (and we haven't even found them all yet). > I'd much prefer we just focus on fixing the posted proposal > (e.g. address data associations). I don't think we collectively have > the bandwidth to start over with a new direction and discussion. We'll take more time working through the current poor modeling idea. It adds a new concept that needs to be coordinated with an existing one, both in tools in in the modeler's understanding. The problem Steve stated was simple: he wants the runtime objects to be the same for multiple data objects. Just have an association between data objects saying that. I'll bet a beer there would be less discussion with this approach. Conrad |
| Comment by Conrad Bock (NIST) [ 07/Apr/10 08:40 AM ] |
|
Suzette, et al,
One question to be addressed in the object ref proposal (which I'm happy to update, my opposition is still loyal!) is how to explain the new concept. For example: - What will we say the modeler is defining? Eg, should the captions for the figures showing the icons say they are data objects or data object refs? - If they are defining data objects, how do we explain that the metaclass is different? Tom asked a number of times during the OMG meeting about this topic, but I didn't have a good answer, and didn't attempt to deal with it in the proposal. Conrad |
| Comment by Suzette Samoojh (IBM) [ 07/Apr/10 05:00 PM ] |
|
Thanks. I'd prefer to continue down the data object ref path.
[Although the "bet a beer" challenge did catch my attention ;-)] - The figure captions should say 'Data Object'. I really don't want to introduce a new concept for modelers at this stage. - Maybe some text in the spec along the lines of: The Data Object Reference is used for each occurrence (or usage) of a particular Data Object within the process. |
| Comment by Suzette Samoojh (IBM) [ 07/Apr/10 05:01 PM ] |
| Actually, it might be useful to look at the DataStore section (pdf pgs 216-218). It has similar challenges. The write-up there looks reasonable to me, and so is probably a pattern we can duplicate. |
| Comment by Conrad Bock (NIST) [ 08/Apr/10 08:33 AM ] |
|
Suzette,
> The figure captions should say 'Data Object'. I really don't want > to introduce a new concept for modelers at this stage. I couldn't have said it better myself. :) > Actually, it might be useful to look at the DataStore section (pdf > pgs 216-218). It has similar challenges. The write-up there looks > reasonable to me, and so is probably a pattern we can duplicate Yes, that's how I wrote the DataObjectRef proposal, basically glossing over everything the way DataStoreRef does. DataStoreRef would actually be easier to explain if we needed to, because there's something external to the process being referenced. Conrad |
| Comment by Reiner Hille-Doering [ 14/Apr/10 09:35 AM ] |
|
Hi Conrad,
we found some problems with your proposal that might need further discussion: 1. As DataObjectReference inherits from ItemAwareElement, it also inherits "itemSubjectRef". As this is redundant with the "itemSubjectRef" in the referenced DataObject, it would be desirable to add a constraint, that the that Data Object Reference MUST NOT have own structureDef. 2. The same is also true for Data Store Reference 3. DataState is contained in DataObjectReference, so the multiplicity on the DataObjectReference side must be 1 and not *. The same mistake was already in the former spec where DataState was still contained in ItemAwareElement (e.g. Figure 10.48). 4. If reference from ItemAwareElement to DataState is removed (and replaced with the new reference on DataObjectReference), some currently possible usage of DataState on other ItemAwareElement-inheriting classes are invalidated. Especially the sections before Figure 10.57 and 10.59 mention that also DataInputs and DataOutputs could have states. Personally I don't unsterstand why DataInputs and DataOutputs need states (and formally with current MM also Properties and DataStores could have them, which also doesn't make sense to me). So if we could agree that only DataObjects need states, we could get rid of the DataState class completely. Which brings me to 5. With your proposal a Shape that depics a DataObjectReference has 3 names that is can choice or combine for its label: From DataObjectReference (inherited from FlowElement), from DataObject ((inherited from FlowElement) and from DataState. If we consider that DataStates are in fact only a way how to give a usage or depiction of a DataObject a special name and maybe some extension attributes, than removing the DataState class is also a good choice: Tools could give the DataObjectReference a name that describe the state and the structure comes from referenced DataObject. Reiner. |
| Comment by Mariano Benitez (Oracle) [ 14/Apr/10 10:06 AM ] |
|
Reiner,
Altough I in general agree with your comments, Conrad's proposal would only focus on DataObjectRef. As for the dataState in the refs (dataObject and dataStore), they are currently allowed and we should be consistent, none of the refs define state or all of them. I believe removing DataState from ItemAwareElement might be good, but it is a different issue, and certainly not for now. The label for depicting a data object ref always use the information of the referenced data object (I believe for data store is similar) My 2c. |
| Comment by Conrad Bock (NIST) [ 14/Apr/10 11:10 AM ] |
|
Reiner,
we found some problems with your proposal that might need further discussion: > 1. As DataObjectReference inherits from ItemAwareElement, it also > inherits "itemSubjectRef". As this is redundant with the > "itemSubjectRef" in the referenced DataObject, it would be desirable > to add a constraint, that the that Data Object Reference MUST NOT > have own structureDef. Yes, this is in the proposal, see addition to Section 10.3.1. > 2. The same is also true for Data Store Reference This is a separate issue. > 3. DataState is contained in DataObjectReference, so the multiplicity > on the DataObjectReference side must be 1 and not *. The same mistake > was already in the former spec where DataState was still contained in > ItemAwareElement (e.g. Figure 10.48). Thx, I can fix it for Data Object Reference in this issue. > 4. If reference from ItemAwareElement to DataState is removed (and > replaced with the new reference on DataObjectReference), currently > possible usage of DataState on other ItemAwareElement-inheriting > classes are invalidated. Especially the sections before Figure 10.57 > and 10.59 mention that also DataInputs and DataOutputs could have > states. > Personally I don't unsterstand why DataInputs and DataOutputs need > states (and formally with current MM also Properties and DataStores > could have them, which also doesn't make sense to me). So if we > could agree that only DataObjects need states, we could get rid of > the DataState class completely. Which brings me to My understanding is ItemAwareElement and DataI/O have states to be able to specify items in that state (for Data I/O that inputs and outputs are in the specified state). Removing it would be a different issue. > 5. With your proposal a Shape that depics a DataObjectReference has 3 > names that is can choice or combine for its label: From > DataObjectReference (inherited from FlowElement), from DataObject > ((inherited from FlowElement) and from DataState. If we consider that > DataStates are in fact only a way how to give a usage or depiction of > a DataObject a special name and maybe some extension attributes, than > removing the DataState class is also a good choice: Tools could give > the DataObjectReference a name that describe the state and the > structure comes from referenced DataObject. Could require the name of the referenced Data Object be displayed. Conrad |
| Comment by Conrad Bock (NIST) [ 14/Apr/10 02:22 PM ] |
|
-----------Proposal----------------Apr 14, 2010---------------------------
##Proposed Resolution: Fixed This issue concerns multiple data objects icons appearing on the same diagram, but with the same name and different states, intending to represent the same runtime object for the duration of each execution of the diagram. The resolution addresses abstract syntax for this, leaving execution semantics to be filed as an issue in the RTF. In the sentence above Figure 10.47 (ItemAware class diagram), after "Data Objects," add "Data Object References,". In Figure 10.47 (ItemAware class diagram) add metaclass named "DataObjectReference", subclass of ItemAwareElement. DataObjectReference has one unidirectional association from it to DataObject. This association has multiplicity * on the DataObjectReference end and 1 on the DataObject end. The name on DataObject end is named dataObjectRef. In Section 10.3.1 (Data Modeling), Data Objects subsection, at the end of the first paragraph, add: Data Object References are a way to reuse Data Objects in the same diagram. They can specify different states of the same data object at different points in a process. Data Object Reference cannot specify item definitions, and Data Objects cannot specify states. The names of Data Object References are derived by concatenating the name of the referenced Data Object with the state of the Data Object Reference in square brackets as follows: <Data Object Name> [ <Data Object Reference State> ]. In Figure 10.48 (DataObject class diagram) add metaclass named "DataObjectReference", subclass of FlowElement and ItemAwareElement. DataObjectReference with one unidirectional associations from it to DataObject as described above for Figure 10.47. Under Table 10.47 (DataObject model associations) add the paragraph: The DataObjectReference element inherits the attributes and model associations of ItemAwareElement (see Table YYY) and FlowElement (see Table 8.45). Table XXX presents the additional attributes of the DataObjectReference element: After the above paragraph add a new model association table with caption "DataObjectReference" with one row: - dataObjectRef : DataObject The DataObject referenced by the DataObjectRef. In Section 10.3.1 (Data Modeling), Lifecycle and Visibility subsection, second paragraph, at the end of the last sentence, add ", including Data Object References referencing the Data Object." |
[BPMNFTF-539] [Diagram Interchange] Stylesheet
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
The DI and more particularly the BPMN DI introduces the notion of "cascading style sheets". The following precedence rule was favored in BPMN DI: Element, Local or current Style, Master Style, Default. The style at the element level on an attribute by attribute base overrides the styles inherited from above. This means that if a Master Style specifies that all shapes should be blue with a texture gradient, one can only specify the color red for a specific shape at shape level and this particular shape will be red and will inherit the texture gradient from the master style while all other shapes will be blue with the texture gradient.
|
| Comments |
| Comment by Denis Gagne [ 01/Mar/10 01:55 PM ] |
| This is a simple common sense approach that does not require to respecify attributes inherited from above. |
| Comment by Denis Gagne [ 03/Mar/10 03:39 PM ] |
|
Posted By Denis on behalf of Burce Silver re: Alternative BPMNDI proposal from Bruce Silver
539 - CSS. I don't remember if I kept that or not, think I did. In any case I have no objection to this. |
| Comment by Ivana Trickovic [ 11/Mar/10 08:56 AM ] |
|
As per March F2F Meeting:
- We included everything that is necessary, but no style information. There is desire to discuss this again in the RTF. Close it. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:36 PM ] |
|
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-538] [Diagram Interchange] Containment structure
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
The BPMN DI baseline proposal does not capture element specific containment structure. The BPMN DI has the notions that a BPMNShape can be an "atomic visual shape" or can be a BPMNPlane providing the layout of the "content" (e.g. Pool, Lane, Sub process, etc). This has the effect that the actual containment relationship is only maintained in the semantic and is not duplicated and thus directly accessible only from the DI. (For example in the case of matrix layout of lanes an element belonging to both and horizontal lane and a vertical lane in the semantic, the element could find itself at the root plane, the vertical lane plane or the horizontal lane plane. A best practice of having elements at the root plane could be advised in such case).
An alternative approach could be to have notions of element specific containers such as laneplanes, subprocesplanes, etc. This would make navigation and awareness of the containment structure possible from only the DI but the disadvantage of duplicating information available in the semantic. |
| Comments |
| Comment by Denis Gagne [ 01/Mar/10 01:53 PM ] |
| The approach taken allow simple handling of less used layout possibilities in BPMN such as matrices of lanes or activities depicted ocross multiple lanes. |
| Comment by Denis Gagne [ 03/Mar/10 03:41 PM ] |
|
Posted by Denis on behalf of Bruce Silver re: Alternative BPMNDI proposal from Bruce Silver
538 - This is the heart of the disagreement. I don't believe planes add value, only potential for conflict. I don't agree with the statement in 538 that even though a shape is nested inside a plane in the serialization, that doesn't really imply "actual" containment, which is governed by the semantic model. You give the example of matrix lanes - who came up with that one? - in which a shape could be simultaneously in a horizontal lane and a vertical lane. Presumably it could be serialized in either plane (for the horizontal and vertical lanes) or the root plane, and it wouldn't matter since the semantic model holds the containment. I think this all proves my points: a) the planes do not add value, only confusion; b) diagram interchange is hurt because tool A requires everything in the root plane and tool B allows choice of planes in this example. You can model it either way but tool A and tool B are no longer interoperable (as far as the graphics are concerned). My proposal eliminates nested planes, a diagram = root plane (no other planes exist) = page, shapes are not nested but placed in a single coordinate space for the entire diagram. I do not see the justification for nesting planes (each with its own coordinate space). |
| Comment by Ivana Trickovic [ 09/Mar/10 11:31 PM ] |
|
As per March F2F Meeting:
- Two options discussed: (1) keep containment structure and introduce validation rules; (2) remove the containment structure. - Pros and cons for the two options will be prepared by Thu (March 11) morning: short discussion on Thu and take straw poll. - On Monday (March 15) the team to make decision which way to take. |
| Comment by Ivana Trickovic [ 11/Mar/10 08:22 AM ] |
|
As per March F2F Meeting:
Agreed to have flat structure and introduce containment structure if it is absolutely necessary. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:35 PM ] |
|
##Proposed Resolution: Close, No Change
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-537] [Diagram Interchange] Sub typing BPMN DI elements vs grab bag attributes
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
In an effort to not duplicate any information that is neither present nor derivable from the semantic model a grab bag approach was taken in the BPMNShape element for 4 visual attributes rather than duplicating the element type information contained in the semantic.
1) isHorizontal : Applies only to semantic context of type Laneset and Participant 2) isWhiteBox: Applies only to semantic context of type Participant 3) isExpended: Applies only to semantic context of type SubProcess and AdhocSubProcess,.... 4) isMarkerVisible: Applies only to semantic context of type Exclusive Gateway |
| Comments |
| Comment by Denis Gagne [ 01/Mar/10 01:50 PM ] |
| I believe this to be the best approach gievn the alternative of duplicating element types in the DI. |
| Comment by Denis Gagne [ 03/Mar/10 03:41 PM ] |
|
Posted by Denis on behalf of Bruce Silver re: Alternative BPMNDI proposal from Bruce Silver
537 - I have this in my xsd as well. No issue. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:32 PM ] |
|
As per March F2F Meeting:
- The current proposal introduces no duplication, but there is "unintended" inheritance which causes more work for tool vendors. So subtyping might be more useful for tools vendors. - Still the decision is to keep the current approach in the proposal. |
| Comment by Ivana Trickovic [ 11/Mar/10 08:25 AM ] |
|
As per March F2F Meeting (revised):
- Visual attribute grab bag attributes will remain. It can also be used to remove ambiguity in the collaboration diagram (re. Participants). |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:37 PM ] |
|
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-536] [Diagram Interchange] Duplication of Source and Target information from the BPMN Semantics to the BPMN DI
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
The BPMN DI subgroup was mandated by the general FTF to create a BPMN DI schema that will only contain information that is neither present nor derivable from the semantic model. In preparing the BPMN DI baseline proposal duplication of Source and Target were introduced in the BPMNEdge element to address the following cases:
1) Visual element without a semantical element to reference (e.g. conversation link). Given that no semantical element can be referenced the target and source are required as these only exist in the BPMN DI. a. This would also apply to visual extensions that are associated to element of the process diagrams but are not in the semantic (e.g. yellow sticky notes) 2) A semantical element that can be depicted many times (e.g. DataObject). It is possible to depict the same semantical DataObject many times on a diagram. We thus need target and source in DI to link the correct visual instance as they all depict the same semantical element. Possible Remedy: In order to remove this duplication, a semantic element should exist from every depictable element. Sub-issue: If Source and Target duplication is maintained then maybe they should be made optional and only used in the above particular cases. The fact is that currently the BPMNEdge is of type DI:LabeledEdge, to have the Source and Target as optional would imply making them optional in the generic DI (Non BPMN domain specific) and that may not be desirable to the community of other domains. |
| Comments |
| Comment by Reiner Hille-Doering [ 01/Mar/10 10:33 AM ] |
|
I like the existence of the source and target references in the DI model, as they allow to validate - and even render - at least the rough diagram of boxes and connection lines without understanding the semantic model. This makes tool design easier.
The little redundance with the semantic metamodel should be acceptable. |
| Comment by Denis Gagne [ 01/Mar/10 01:48 PM ] |
|
I would go the other way.
We should ensure that only explicit semantical elements are depictable. (i.e. there has to be a semantical element for each depicted edge or shape in a BPMN diagram.) Thus remove the need for dupication. If we maintain the duplication of the Target and Source (and Router) , I would strongly recommend that we make these "optional" and that they be used only when the information is not present in semantic (i.e. for conversation links) Well at the very least in the schema. I understand the ramifications to other domains (UML, SysML etc) of making these optional, (because of the BPMN DI inheriting from the DI) but the Domain Specific DI for these domain could have them required in their own DSLDI. |
| Comment by Denis Gagne [ 03/Mar/10 03:42 PM ] |
|
Posted by Denis on behalf of Bruce Silver re: Alternative BPMNDI proposal from Bruce Silver
536 - Replicating semantic info via source and target refs for connectors. Yes mine has xy not shapeRef for source/target, but this is not a big deal for me. You can get the source/target from the semantic connector reference, but this is a minor point. I can go either way. |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 11:21 AM ] |
|
Case 1 is also being tracked in Case 2 is being tracked/discussed in |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 11:23 AM ] |
|
Actually Case 2 is also being discussed in Having multiple issues makes it difficult to know if the conversations/discussions are being held with the right people and with the same people. |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 11:35 AM ] |
|
Is the DI covering the case of a Data Object that has a Data Association to a Sequence Flow? Note that in the semantic model, there would be no Data Association to the Sequence Flow. Rather the spec currently treats this as a 'visual short cut'. See the Beta Spec, pgs 202-203.
Is this another to add to the list of problematic scenarios? |
| Comment by Ivana Trickovic [ 09/Mar/10 11:33 PM ] |
|
As per March F2F Meeting:
- Make source and target optional. If questions (1) and (2) listed in the issue description are resolved maybe we do not need them. But this decision can be made later. |
| Comment by Denis Gagne [ 10/Mar/10 11:29 AM ] |
| There also a case for target and souce duplication for message flow that either end at the border of the black box pool rather than to the actual internal flow element. |
| Comment by Ivana Trickovic [ 11/Mar/10 08:13 AM ] |
|
As per March F2F Meeting (revised):
Source and target will not be removed. They will be made optional. In case the information (semantic reference) is not there then it must be specified. Add such cases in section 13. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:36 PM ] |
|
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-535] [OMG 15071] Enforcability rules not complete
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Alistair Barros |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Choreography FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Enforcability rules not complete. Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Filed for Alistar: Enforcability rules not complete. ##Proposed Resolution: Defer The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF |
| Comments |
| Comment by Stephen White [ 18/Mar/10 04:14 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-534] [OMG 15070] Notation for shared correlation properties
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Notation, SoaML |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Conversation FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Correlation on message flow and choreography activitiesNotation for shared correlation properties. Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Filed for Alistar: Conversations / communications sharing correlation properties should be linked graphically. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 16/Mar/10 02:44 PM ] |
| Per request of conrad changed the issue title. |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 09:56 AM ] |
| proposalScheduledForBallot10 |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 08:56 AM ] |
| New Proposed Resolution: Defer |
| Comment by Ivana Trickovic [ 05/Apr/10 12:11 AM ] |
| Update the proposed issue resolution to say that this is a request for an enhancement, but those not represent an implementation issues. So the FTF agreed to defer it and leave this issue in the wish list for the RTF. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:24 PM ] |
|
##Proposed Resolution: Defer
This is a request for a new graphical element. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-533] [OMG 15069] Correlation on message flow and choreography activities
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Choreography FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Correlation on message flow and choreography activities Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Should be able to specify correlation directly on message flow and choreography activities, without the overhead of conversations. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 16/Mar/10 06:45 AM ] |
| Removed issue from Ballot so Conrad can make a proposal. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:58 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 09/Apr/10 09:19 AM ] |
|
-----------Proposal----------------Apr 9, 2010---------------------------
##Proposed Resolution: Fixed Choreography activities are a way of grouping message flow and should have correlation like other message flow grouping constructs. Message flows themselves do not need correlation, because correlation only works if the same key values are in more than one message flow, as identified by message flow grouping constructs. Remove Subsection 12.3.3 (Correlations) and the sentence in it. In Figure 12.6 (The metamodel segment for a Choreography Activity) add the CorrelationKey metaclass with a unidirectional association to it from ChoreographyActivity. This association has multiplicity 0..1 on the ChoreographyActivity end and * on the CorrelationKey end. The association end on the CorrelationKey end is named correlationKeys, which has composite aggregation (the black diamond appears on the opposite end). In Table 12.2 (Choreography Activity Model Associations) add a row at the end: - correlationKeys : CorrelationKey [0..*] This association specifies correlationKeys used by the message flow in the choreography activity, including subchoreographies and called choreographies. In Table 12.11 (ChoreographyActivity XML schema), after the participantRef element attribute, insert on a new line: <xsd:element ref="correlationKeys" minOccurs="0" maxOccurs="unbounded"/> |
| Comment by Reiner Hille-Doering [ 19/Apr/10 06:47 AM ] |
|
Conrad,
I think that CorrelationKeys should not be contained (composite aggregation) in the C-Activity. CorrelationKeys are contained in the Collaboration (after C-merge), right? Anyway, I see a similar issue for the orchestration elements that use correlation, mainly intermediate events and receive tasks. I asked myself and Karsten, which element should be referenced from those elements. Maybe it is not the CorrelationKeys, but Correlation, CorrelationProperty or even a CorrelationSubstription. But I must admit that I don't understand the intetion in the Correlation MM part enough to just this. I would be happy if we have a consistent way to express a subription for both, C-Activity and IntermediateEvent/ReceiveActivity. Reiner. |
| Comment by Conrad Bock (NIST) [ 19/Apr/10 08:31 AM ] |
|
Reiner,
> I think that CorrelationKeys should not be contained (composite > aggregation) in the C-Activity. CorrelationKeys are contained in the > Collaboration (after C-merge), right? Yes, any of the message flow "grouping" mechanisms can have correlation keys. For example, collaborations and conversation nodes (subs, calls, and regular conversations). Choreography activities are another way message flow, and can have correlation also for consistency. Then if it happens that the choreography activities group message flow with the same correlation keys, it isn't necessary to define conversations just to have correlation. > Anyway, I see a similar issue for the orchestration elements that use > correlation, mainly intermediate events and receive tasks. I asked > myself and Karsten, which element should be referenced from those > elements. The definitional collaboration provides correlation to process elements by the grouping of message flow linked to events and tasks, see below. > Maybe it is not the CorrelationKeys, but Correlation, > CorrelationProperty or even a CorrelationSubstription. But I must > admit that I don't understand the intetion in the Correlation MM part > enough to just this. The term "correlation" refers to the CorrelationKey /Property / Subscription, etc, elements that model it. There isn't a Correlation element by itself. I agree the explanation of correlation in the spec could be improved. > I would be happy if we have a consistent way to express a subription > for both, C-Activity and IntermediateEvent/ReceiveActivity. Correlation is applied to groups of message flows, because it is only when there are multiple message flows between participants that the problem occurs of assigning incoming message instances to process instances. So you don't see correlation applied to single message flow, or events/tasks (which are linked to one message flow). The discussion a while back settled on using definitional collaboration to specify the groups of message flows and their correlation for processes. Conrad |
| Comment by Reiner Hille-Doering [ 21/Apr/10 07:51 AM ] |
|
Thanks Conrad, with the help of your comments and the example that Matthias sent to me, I understand the concept now much better. Now it is completely clear to me how this message flow grouping does do the job of correlation.
There are two little changes in Figure 8.18 that should be fixed, but Ivana will find a new Jira for this: - A missing Diamond (composite) between CorrelationPropertyRetrievalExpression and FormalExpression. - Good to have also the MessageFlow in this diagram to understand how Conversations group them together with CorrelationKeys. Reiner. |
[BPMNFTF-532] [OMG 15068] Label call conversation links
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Notation, SoaML |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
callconversation-532-v2.ppt
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Conversation FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Label call conversation links Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Filed for soaML: Links from call conversations should be labelled with participant names of the called conversation, as identified by nonvisual participant associations. |
| Comments |
| Comment by Conrad Bock (NIST) [ 15/Mar/10 10:53 AM ] |
|
Denis says DI requires conversation links in the abstract syntax
(metamodel) to support this. |
| Comment by Stephen White [ 19/Mar/10 03:11 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 02:53 PM ] |
|
Conversation links in abstract syntax are not required for this, since
the name in labels is the name of the nested participants, rather than the link. |
| Comment by Denis Gagne [ 08/Apr/10 10:58 AM ] |
|
The point was not about the Label !!
You realise that without an abstract syntax the Conversation Links do not exists. They are pure visual decorators. As such, their visualization requires tool to make inferences that I cannot even understand how to resolve now. I assume an end user would expect such visual depiction to be interchanged between tools. On top this is the only situation remaining where something is depicted (with business semantic) but that does not have a MM element. If it has Buiness Semantic it should have MM element. I am still not clear with this proposal how to handle Conversation link with multiple connections (and what the lable would then be). |
| Comment by Conrad Bock (NIST) [ 13/Apr/10 01:54 PM ] |
|
-----------Proposal----------------Apr 13, 2010---------------------------
##Proposed Resolution: Fixed This resolution assumes the resolution of Replace the paragraph at the end of Section 11.7 (Communication Link), the one beginning "There is not a specific BPMN metamodel", with the following: Conversation links for call conversations show the names of participants in nested collaborations or global conversations, as identified by participant associations. For example, Figure XXX has a collaboration on the left with a call conversation to a collaboration on the right. The conversation links on the left indicate which participants in the called collaboration on the right correspond to which participants in the calling collaboration on the left. For example, the Credit Agency participant on the right corresponds to the Financial Company participant on the left. Participant associations (not shown) tie each participant in the collaboration on the left to a participant in the collaboration on the right. They can be used to show the names of participants in nested collaborations or global conversations. After above text, insert a figure with caption "Call Conversation Links", and contents per the attached document: http://www.osoa.org/jira/secure/attachment/10699/callconversation-532-v2.ppt. |
[BPMNFTF-531] [OMG 15067] Hexagons and message flow linked to activities
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Notation, SoaML |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Issue 531 figures-v2.doc
Issue 531 figures-v3.doc
Issue 531 figures-v3.doc
screenshot-1.jpg
screenshot-2.jpg
screenshot-3.jpg
screenshot-4.jpg
|
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Conversation FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Hexagons and message flow linked to activities Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Filed for soaML: It should be possible to link hexagons (conversations / communications) to activities. This would mean messages flow from within the activity, which could be calls or subs. The hexagon can be expanded to show message flow connected to the activity, including calls and subs. |
| Comments |
| Comment by Stephen White [ 19/Mar/10 03:11 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 17/Apr/10 10:47 AM ] |
|
-----------Proposal----------------Apr 17, 2010---------------------------
##Proposed Resolution: Fixed Conversation links are groupings of message flows, so they can be linked to activities and events just as message flow can. The resolution supports conversation links to activities and events, but not message flow to conversation nodes a requested by the issue. This restriction is only by textual constraint, if a future RTF would like to loosen it. Conversation Link is added to the metamodel to simplify implementation of this resolution. The notation for conversation links is changed to a double lines, to distinguish them from sequence flows when used with activities and events. The forked line end notation for conversation links ("crow's feet") is removed to simplify usage and implementation, since it is redundant with participant multiplicity notation. The resolution assumes the resolution of Refer to attached document http://www.osoa.org/jira/secure/attachment/10725/Issue+531+figures-v3.doc for figures. In the BPMN Core Structure chapter, Message Flow subsection, in the figure The Message Flow Class Diagram, rename MessageFlowNode to InteractionNode, add ConversationNode as a subclass, and its association to Participant. See first figure in attached document. In the BPMN Core Structure chapter, Message Flow subsection, in the table Message Flow attributes and model associations: - replace "MessageFlowNode" with "InteractionNode" in the first two rows, both columns. - In the first two rows, right column, at the end of the sentences, add "of a Message Flow". In the BPMN Core Structure chapter, Message Flow section, Message Flow Node subsection: - Change the title of the subsection to Interaction Node - In the two paragraphs of the subsection, replace the two occurrences of "MessageFlowNode" in each paragraph with "InteractioNode". - In the first paragraph, delete the portion of the sentence starting with "and thus" to the end of the sentence. - At the end of the first paragraph, add the sentence "The InteractionNode element is also used to provide a single element for source and target of Conversation Links, see chapter XXXCollaboration. In the Collaboration section, in the figure Classes in the Collaboration package, add ConversationLink and InteractionNode and their associations and generalizations to other elements, see second figure in the attached document. In the Collaboration chapter, Participants section, in the figure The Participant Class Diagram, change the name of the MessageFlowNode metaclass to InteractionNode. See third figure in attached document. In the Collaboration section, in the table Collaboration Attributes and Model Associations, after the row for conversations, insert a new row: - conversationLinks: ConversationLink [0..*] This provides the Conversation Links that are used in the Collaboration. In the Collaboration chapter, Conversations section, at the end of the first paragraph, add the sentence "In particular, processes can appear the participants (pools) of conversation diagrams, to show how conversations and activities are related." In the Collaboration chapter in the Conversation Link section (was CommunicationLink before resolution of the figure A Conversation Link element, insert a new figure captioned "The Conversation Link Class Diagram", showing ConversationLink and related classes, see the fourth figure in the attached document. After the above new figure, insert: The Conversation Link element inherits the attributes and model associations of BaseElement (see Table XX). Table XXXX presents the additional attributes and model associations for the Conversation Link element: then insert a table with the caption "Conversation Link attributes and model associations", and two columns headed "Attribute Name" and "Description/Usage" with the rows: name : String [0..1] Name is a text description of the Conversation Link. sourceRef: ConversationLinkNode The ConversationLinkNode that the Conversation Link is connecting from. A Conversation Link MUST connect to exactly one ConversationNode. If the sourceRef is not a ConversationNode, then the targetRef MUST be a ConversationNode. targetRef: ConversationLinkNode The ConversationLinkNode that the Conversation Link is connecting to. A Conversation Link MUST connect to exactly one ConversationNode. If the targetRef is not a ConversationNode, then the sourceRef MUST be a ConversationNode. In the Collaboration chapter in the Conversation Link section (was CommunicationLink before resolution of the figure Where Conversation Links are derived in the metamodel, and the paragraph after it (the last one in the section) and replace it with: Processes can appear in the participants (pools) of Conversation diagrams, as shown in Figure XXXX. The invoicing and ordering conversations have links into activities and events of the process in the Order Processor. The other two conversations do not have their links "expanded". Conversation links into activities that are not send or recieve tasks indicate that the activity will send or receive messages of the conversation at some level of nesting. After the above text, insert a figure captioned "Conversation links to activities and events" with the contents of the fifth figure in the attached document. In the Collaboration chapter, in the XML Schema section, in the table for Collaboration XML schema, under the conversations element, insert a new line: <xsd:element ref="conversationLink" minOccurs="0" maxOccurs="unbounded"/> In the Collaboration chapter, in the XML Schema section, after the table for Conversations, insert a new table, captioned "ConversationLink XML schema" containing: <xsd:element name="conversationLink" type="tConversationLink" substitutionGroup="rootElement"/> <xsd:complexType name="tConversationLink"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:attribute name="name" type="xsd:string" use="optional"/> <xsd:attribute name="sourceRef" type="xsd:QName" use="required"/> <xsd:attribute name="targetRef" type="xsd:QName" use="required"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> In the Overview chapter, BPMN Scope section, Uses of BPMN subsection, figure An example of a Conversation diagram, on the lines coming out of the hexagons (the conversation links): - Change the line style to double thin lines. - Remove the forking on the participant ends of the lines. In Collaborations chapter, Conversation section, figure A Conversation, figure Conversation diagram depicting several conversations between Participants in a related domain, change the figure in the same way as the figure above. In Process chapter, Activities section, Sub-Processes subsection, Ad-Hoc Sub-Process subsubsection, in the bullet just above figure An Ad-Hoc Sub-Process with data and sequence dependencies, after "Conversation Links" insert "(graphically)". In Collaborations chapter, Conversation section, figure A Conversation diagram, on the lines coming out of the hexagon (conversation links), change the line style to double thin lines. In Collaborations chapter, Conversation section, figure Conversational view choreographies, on the lines coming out of the hexagon (conversation links), change the line style to double thin lines. In Collaborations chapter, Conversation section, COnversation Link subsection: - First paragraph, replace the second sentence with "Conversation links MUST be drawn with double thin lines.". - In figure A Conversation Link element: - On the lines coming out of the hexagon: - Change the line style to double thin lines. - Remove the forking on the participant ends of the lines. - Remove the text annotation on the lower right (the one that says "The Conversation Link source is forked if there are multiple connections"). |
[BPMNFTF-530] [OMG 15066] Notation for expanded hexagons
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Notation, SoaML |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Conversation FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Notation for expanded hexagons Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Filed for soaML: When multiple hexagons (conversation/communication) are expanded, it isn't possible to tell which message flows go with which hexagons, because the hexagons disappear. Should have a grouping notation to show which message flow came from expanding which hexagons. |
| Comments |
| Comment by Stephen White [ 19/Mar/10 03:10 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:27 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Defer This is deferred for more discussion on a notation for this. |
[BPMNFTF-529] [OMG 15065] definitionalCollaborationRef should be 0..*
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Pete Rivett | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Adaptive (Pete Rivett pete.rivett@adaptive.com)
definitionalCollaborationRef should be 0..* Table 10.1, definitionalCollaborationRef includes the phrase "For Processes that interact with other Participants," which implies that Processes *are* Participants. In fact they are distinct elements in the metamodel. More significantly it states "The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow." However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting. |
| Comments |
| Comment by Stephen White [ 24/Feb/10 04:14 PM ] |
|
-------------- Discussed on Conference Call on 2010-02-24 ----------------------------
A process can already be referenced by many collaborations. This is done through the association from Participant. The defintionalCollaboration is for defining the executable and should be complete. Do we need multiple definitionalCollaborations? Different subsets of Pools can be used in each one. Thus, the different collabs would be variations of the same basic model. Can the DI allow for viewing/hiding of participants? Hiding any elements? DI would capture the different views? E.g., expanded/collapsed sub-processes. Conrad will talk with DI How about LaneSets? Could use the one defColl, but have different DI layouts for showing or hiding participants. Overall, we're not sure that the multiplicity needs to be changed, but we will investigate more. |
| Comment by Ivana Trickovic [ 10/Mar/10 11:22 PM ] |
|
As per March F2F Meeting:
- Agreed that we need to keep 0..1 but we need to provide better explanation of the concept. - Definitional Collaboration is the finest granular (complete) collaboration. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:58 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:22 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Defer The same process can appear in multiple collaborations, and must be consistent with all them, so it is unclear why definitional collaboration are any different the others a process appears in. One possibility is to limit correlation to the definitional collaboration. If processes can have multiple definitional collaborations, it needs to be decided which applies when the process is called. This is deferred for more discussion in RTF. |
| Comment by Ivana Trickovic [ 19/Apr/10 07:59 AM ] |
| I suggest to add a clarification in version Beta 1. Multiple definitional collaborations would be a new capability that could be added later. |
| Comment by Ivana Trickovic [ 19/Apr/10 08:04 AM ] |
|
##Proposed Resolution: Fixed
Change in table 10.1 the following text. Include: "The same Process can appear in multiple collaborations. For Processes that interact with other Participants, a definitional Collaboration can be referenced by the Process. The definitional Collaboration is the most complete collaboration that specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow. The definitional Collaboration need not be displayed. Additionally, the definitional Collaboration can be used to include Conversation information within a Process." instead of "For Processes that interact with other Participants, a definitional Collaboration can be referenced by the Process. The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow. The definitional Collaboration need not be displayed. Additionally, the definitional Collaboration can be used to include Con-versation information within a Process." |
| Comment by Conrad Bock (NIST) [ 19/Apr/10 08:44 AM ] |
|
Ivana,
I'm not sure this is enough clarification. For example, it doesn't say whatr "complete" means exactly, and what the non-definitional collaborations are for. Conrad |
| Comment by Gary Brown [ 30/Apr/10 04:02 AM ] |
|
This issue is showing up in the ballot as having two resolutions, and both can be voted on - is this intentional? What if both resolutions get the required number of votes :)
I assume the 'fixed' resolution is the valid one, but currently this is ambiguous in the ballot, so the deferred resolution comment should be deleted. |
[BPMNFTF-528] [OMG 15064] For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Pete Rivett | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Adaptive (Pete Rivett pete.rivett@adaptive.com)
For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty 9.3 title should be "Process within Collaboration" not simple "Collaboration" which is the title for all of section 9. Note that "Process within Collaboration" is also the title of section 10.11 which is completely empty. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:37 PM ] |
| Issue 14654 (JIRA 334) provided the text change for the title of the section. But the contents of the section still need work. |
| Comment by Stephen White [ 18/Mar/10 08:37 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:10 AM ] |
|
Move on ballot #11 to update the specification properly and remove empty section. The final version of the specification shall not contain empty sections.
|
| Comment by Ivana Trickovic [ 19/Apr/10 07:09 AM ] |
| Move on ballot #12 to update the specification properly and remove empty section. The final version of the specification shall not contain empty sections. |
| Comment by Ivana Trickovic [ 20/Apr/10 07:50 AM ] |
|
##Proposed Resolution: Fixed
Make the following changes in Beta 1: Section 9.3: Change the section heading to read "Process within Collaboration" (instead of "Collaboration"). Section 10.11: Remove this (empty) chapter. |
[BPMNFTF-527] [OMG 15063] How to represent Process Diagrams and Lanes?
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Notation, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Pete Rivett | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Adaptive (Pete Rivett, pete.rivett@adaptive.com)
How to represent Process Diagrams and Lanes? Taking Figure 10.121 as an example, it's unclear what the outer box represents in the diagram - is it a graphical Pool representing a Participant named Supplier linked to a PartnerEntityRole also named 'Supplier' in turn linked to a Process also called Supplier? Or is it merely a Process called Supplier (in which case it could be better named 'Supply Process')? I would have thought the latter, but that does not tie in with my reading of 13.2.3 which states that "A Lane is a sub-partition with a Pool" and "A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations." Likewise Figure 13.4 provides only one interpretation - as Lanes within a Pool not within a Process. Though Table 13.1 states that a Process Diagram has at least one LaneCompartment (which is inconsistent with 13.2.3 which states that Lanes are only within Pools) this is inconsistent with the serialization (in Table 10.19) of Figure 10.23 which has no instance of Lane at all. And Figure 10.23 appears to use the Pool notation shown in Figure 13.3 ------------- Proposal -------------- 2010-02-24 ---------------------------- ##Proposed Resolution: Close; No Change Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Feb/10 04:58 PM ] |
|
Figure 10.121 should show at least one other Pool. This would make it clearer. There is another issue raised for this.
---------------- Discussed during Conference Call on 2010-02-24 --------------------------- Figure 10.121: Where does the name of the process when there are lanes? Process names can go any location relative to the Process now But can be confusing when there are Lanes Should we standardize where the Process name should be? Will it improve interoperabiltiy or readability of diagram? No specific place or location for process name. We believe that the spec should leave the location of the process name up to the modeler or tool. Propose to Close; no change |
| Comment by Stephen White [ 24/Feb/10 05:00 PM ] |
|
------------- Proposal -------------- 2010-02-24 ----------------------------
Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification ---------------------------------------------------------------------------------------- |
| Comment by Pete Rivett [ 26/Feb/10 07:17 PM ] |
|
Overall I think this discussion missed a number of aspects in this issue and I'm not happy about it being Closed No Change.
This is an important and fundamental area where, as a vendor with only the spec to go on, I'm *lost* as to how to represent the simplest of Process Diagrams. This in itself indicates at least something needs to change. a) If there is another issue addressing Figure 10.121 then this issue should be closed as Duplicate (referencing that issue) not 'Closed no change'. b) Regardless of whether Figure 10.121 is fixed as suggested, is it the intention that you can *never* document an 'internal' process with multiple lanes and no external pool? If so, such a restriction is not documented AFAIK - and it should be. c) There is still a contradiction with Table 13.1 which states that a Process Diagram has at least one LaneCompartment. So, for this aspect at least, a change to the spec is needed. Likewise Figure 10.23 and the XMI in Table 10.19 is in question: assuming it's a Process Diagram (not made clear) what is the thing labeled 'Buyer'? And should the XML not contain a Lane element corresponding to that LaneCompartment? d) Also I find nothing in the spec that states where a Process name can or should appear. e) Finally, something in this area is likely to need to change as a result of the recent 'ruling' I discovered that Sub-Processes may themselves also have Lanes. |
| Comment by Mariano Benitez (Oracle) [ 03/Mar/10 10:01 AM ] |
| New Proposed Resolution |
| Comment by Falko Menge [ 06/Apr/10 10:32 AM ] |
|
Gerardo and me spent some time reviewing this issue and came to the following conclusions:
a) This issue describes multiple concerns. Hence, it is related but not really a duplicate. b) There is no such restriction. Sections 9.2.1 and 10.7 allow such a process to be modeled and graphically depicted. c) Chapter 13 is currently being rewritten completely by the Diagram Interchange sub-group and will have minimal or no containment relationships at all. Thus, it will no longer enforce processes to contain at least one lane and neither does the meta model (see also Figure 10.122). d) This is not an issue, because it is intentionally left open, as Steve stated earlier. e) If such changes are required, proposals for them should go into the according issue(s). The only remaining problem is that the participant named 'Buyer', which is represented by the pool in Figure 10.23, does not appear in the XMI in Table 10.19. We suggest that the problem with this example should go into a separate issue and we are currently preparing a proposal for fixing the XMI. Hence, we agree to close this issue with no change. |
| Comment by Falko Menge [ 12/Apr/10 12:00 PM ] |
|
Issue |
[BPMNFTF-526] [OMG 15062] Figure 10.121 mis-described
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Pete Rivett | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: Adaptive (Pete Rivett pete.rivett@adaptive.com)
Figure 10.121 mis-described The text beneath it states that it shows "the Lane class diagram": it's not a class diagram at all but a Process Diagram ##Proposed Resolution: Close, No Change In beta version 09-08-14, - Figure 10.121 title is "An Example of Nested Lanes" and it describes a process diagram with lanes. - Figure 10.122 title is " The Lane class diagram" and it describes the UML Class Diagram for Lane and LaneSet |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Apr/10 12:37 PM ] |
|
@Pete: I checked the beta spec (09-08-14.pdf) and the figure titles (10.121 and 10.122) are correct. Can you verify if this it what you reported?
|
[BPMNFTF-525] [OMG 15061] LaneSet should have an optional 'name' attribute
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Notation, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Pete Rivett | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Cordys (Pete Rivett, pete.rivett@adaptive.com)
This is issue # 15061 Pete Rivett" <pete.rivett@adaptive.com> LaneSet should have an optional 'name' attribute Since a LaneSet represents a "a different way" of slicing up a process (e.g. by role or by department) then it should have a name, not just a (potentially unreadable) id to represent that way. Allowing different diagrams for the same Process to be distinguished. There should be also a notation to allow for this: for example <Process Name>: <LaneSet Name> So for example Figure 10.121 would have Supplier: By Department |
| Comments |
| Comment by Stephen White [ 24/Feb/10 05:21 PM ] |
|
----------- Discussed during Conference Call on 2010-02-24 -----------------
LaneSet name Where would the name go? Create a compartment? Use the name of the attribute that defines the LaneSet? LaneSets are not visualized by themselves. Such a name could be used to generate a report, e.g., We should be use name of the attribute for the LaneSet Why is the partitionElement a Base Element and not a property or itemDefinition? We will investigate the construction of Lanes and LaneSets some more |
| Comment by Stephen White [ 01/Mar/10 08:34 PM ] |
|
From Pete Rivett:
I suggested in the issue that the LaneSet name could be shown after a colon. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:17 PM ] |
|
As per March F2F Meeting:
- Agreed to add a name attribute to laneSet, but this will be just a metamodel (structural) change. LaneSets will not be visualized. - We need to assign the issue to someone. |
| Comment by Ivana Trickovic [ 23/Mar/10 03:27 AM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 12/Apr/10 07:48 AM ] |
|
##Proposed Resolution: Fixed
Make the following changes to the MM (version Beta 1) - Add attribute "name" of type "String" to class "LaneSet" Make the following changes to the XSD (version Beta 1) - Change <xsd:complexType name="tLaneSet"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element ref="lane" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> to <xsd:complexType name="tLaneSet"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element ref="lane" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> Make the following changes to the specification text: - Insert a new row at the top of table 10.127 (LaneSet attributes and model associations) with the following content: Column "Attribute Name": name: string Column "Description/Usage": The name of the LaneSet. A LaneSet is not visually displayed on a BPMN diagram. Consequently, the name of the LaneSet is not displayed as well. |
[BPMNFTF-524] [OMG 15060] Simplify Use of Callable Elements
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 8 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 63 Title: Simplify Use of Callable Elements Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Callable elements can be simplified. For example, a Global Choreography Task can be a sub-type of Choreography. It would be defined as an "empty" Choreography. A Global Task could be a sub-type of Process, with the same restriction.By doing this, then calling elements within the diagram can be more specific about what kind of element they can reference. Thus, a CallActivity can reference a Process and a Call Choreography can reference a Choreography, instead of both referencing Callable Elements with an text based restriction as to what kind of callable element can be referenced. ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 22/Feb/10 12:37 PM ] |
| Issue 14654 (JIRA 334), which handles the merging of Conversation and Collaboration, will resolve part of this issue. The merger will propose this simplification for Choreography and Collaboration. If that issue is passed, then this issue (15060) will only have to deal with the Process and Global Task relationship. |
| Comment by Stephen White [ 24/Feb/10 05:17 PM ] |
|
----------- Discussed during Conference Call on 2010-02-24 -----------------
Define Global Task as a sub-type of Process. Process that has nothing in it is the same as Global Task? Removes textual constraints? A generalization restriction is better than reference restriction? The interface and IOspecs are not appropriate for Callable Element But the concepts of Process and Global Task are too different. Global Task would inherit too many extraneous attributes from Process. Instead, add a superclass for process and global Task and move interface info to that class Such a proposal will be generated |
| Comment by Conrad Bock (NIST) [ 26/Feb/10 07:46 AM ] |
|
Comment from Suzette during Feb 25 conference call: when Collaboration
and Conversation are merged, InteractionSpecification no longer needs to be a CallableElement. CallableElement can be renamed to apply just to Process and Global Task. |
| Comment by Stephen White [ 18/Mar/10 08:33 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 30/Mar/10 12:42 PM ] |
| New Proposed Resolution |
[BPMNFTF-523] [OMG 15059] DataInputs, DataOuputs, and DataStores should be FlowElements
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White, wstephe@us.ibm.com)
******************************************************************************* Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 8 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 76 Title: DataInputs, DataOuputs, and DataStores should be FlowElements Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Data Object is a Flow Element because it can apppear in a Flow Element Container (e.g., a Process). Data Inputs, Data Outputs, and Data Stores should also be Flow Elements for the same reason.These elements would not need there own name attribute in this case. ------------------- Proposal ------------ 2010-02-22 ------------------------ ##Proposed Resolution: Close; No change Close, no Change. The FTF decided that the reported issue does not identify a problem with BPMN 2.0 ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 19/Feb/10 02:45 PM ] |
|
I took a closer look at these elements, to see if I could recall why we didn't make them Flow Elements originally.
- Data Store should not be a Flow Element. It doesn't appear in the diagram. It's the Data Store Reference that appears, and it is already a Flow Element. - The problem with Data Inputs and Data Outputs is, while they may visually appear inside of a Flow Element Container, they are actually contained by the InputOutputSpecification. And of course, they may be owned by a Task, and hence are not visualized at all. Making them Flow Elements will create confusion within the metamodel wrt their containment. Consider a Data Input for a process. Would the Data Input be contained by the InputOutputSpecification of the process, or would it be contained directly by the process (via the flow element containment)? The former is what we want. And so we shouldn't enable the latter by making Data Inputs and Data Outputs inherit from Flow Element. Recommend we close with no change. |
| Comment by Stephen White [ 22/Feb/10 03:48 PM ] |
|
For Robert Shapiro:
DataInput and DataOutput both have visual representations defined in the spec. But in the absence of some example diagrams, it is really unclear how they should be used and what the distinction is between using them to show the inputs and outputs of a process versus the inputs and the outputs of an activity. Since the representation of both of these elements is based on the representation of DataObject, we need to also look at DataObject. It has its own problem in semantic.xsd. There can be multiple visible occurrences of the same DataObject according to the spec. But this seems to be wrong: there should be multiple occurrences of DataObjectRef, each referring to the same DataObject, as was done with DataStore and DataStoreRef. |
| Comment by Stephen White [ 22/Feb/10 03:55 PM ] |
| A separate issue for the use of Data Objects will be generated. |
| Comment by Stephen White [ 22/Feb/10 03:58 PM ] |
|
------------------- Proposal ------------ 2010-02-22 ------------------------
Close, no Change. The FTF decided that the reported issue does not identify a problem with BPMN 2.0 ---------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 22/Feb/10 03:58 PM ] |
| New Proposed Resolution |
[BPMNFTF-522] [OMG 15058] CorrelationKey should be a concrete element
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White, wstephe@us.ibm.com)
******************************************************************************* Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 8 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 66 Title: CorrelationKey should be a concrete element Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The CorrelationKey element is currently an abstract element in the metamodel. Since it has no concrete sub-classes, it should made a concrete class -----Proposal---------------- 2010-02-24 ------------------------- ##Proposed Resolution: Fixed (a) Update Figure 8.18, page 66 (96 pdf) to show that CorrelationKey is a concrete class (b) Update XSD schema to reflect the above change ----------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Feb/10 05:05 PM ] |
|
-----Proposal---------------- 2010-02-24 -------------------------
(a) Update Figure 8.18, page 66 (96 pdf) to show that CorrelationKey is a concrete class (b) Update XSD schema to reflect the above change ----------------------------------------------------------------------------- |
| Comment by Stephen White [ 24/Feb/10 05:05 PM ] |
| New Proposed Resolution |
[BPMNFTF-519] [OMG 15055] Required definitions to invoke an existing function by means of a service task
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank Leymann | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMN Service Invocation - Questions.docx
|
| Description |
|
*******************************************************************************
Name: Frank Leymann Company: IBM mailFrom: Leymann@iaas.uni-stuttgart.de Notification: Yes Specification: OMG Section: 8.4 Services FormalNumber: BPMN 2.0 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 107 ff Title: Required definitions to invoke an existing function by means of a service task Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: It is not precisely defined what definitions must be made in order to specify that a particular executable is to be invoked as an implementation of an operation of a service task (for example). The specification should clearly spell out which definition are mandatory in order to capture the major scenarios, e.g. using an operation of WSDL port; using a java class;... I submitted a document with more details on the problem area to issues@omg.org, without any response since weeks. I am happy to send this document to the person assigned to this issue, and discuss it. The document is here: http://www.osoa.org/jira/secure/attachment/10618/BPMN+Service+Invocation+-+Questions.docx ##Proposed Resolution: Fixed - To "Table 8.80 - Interface attributes and model associations", add the following row: implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that interface, such as a WSDL porttype. - To "Table 8.81 - Operation attributes and model associations", add the following row: implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that operation, such as a WSDL operation. - Update the UML meta-model and XSD schema accordingly. |
| Comments |
| Comment by Tammo van Lessen [ 25/Feb/10 08:56 AM ] |
| Frank's document attached. |
| Comment by Matthias Kloppmann (IBM) [ 03/Mar/10 12:19 PM ] |
|
Add two attributes, to implementation and operation, to reference the actual interface in the particular technology being used:
- interface/@implementationRef: Element[0..1] -- in XSD will become QName - operation/@implementationRef: Element[0..1] -- in XSD will become QName |
| Comment by Matthias Kloppmann (IBM) [ 03/Mar/10 12:27 PM ] |
| Leave inputSet and outputSet as is -- XML will typically not be created manually anyway, but by tools, so mandating that even if there is a single one doesn't hurt. |
| Comment by Tammo van Lessen [ 03/Mar/10 01:09 PM ] |
| Explicit data assignments can be done via a script task with no script but ioSpecification with assignments. Alternatively, the assignment logic can be put into a script. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 08:54 AM ] |
|
Full summary of required changes:
- To "Table 8.80 - Interface attributes and model associations", add the following row: implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that interface, such as a WSDL porttype. - To "Table 8.81 - Operation attributes and model associations", add the following row: implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that operation, such as a WSDL operation. - Update the UML meta-model and XSD schema accordingly. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 08:54 AM ] |
| New proposed resolution |
[BPMNFTF-518] [OMG 15054] Redundancy in specifying data in processes
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank Leymann | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Unresolved | Votes: | 0 |
| File Attachments: |
BPMN Data Handling - Questions.docx
|
| Description |
|
*******************************************************************************
Name: Frank Leymann Company: IBM mailFrom: Leymann@iaas.uni-stuttgart.de Notification: Yes Specification: OMG Section: 10.3 Items and Data FormalNumber: BPMN 2.0 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 181 ff Title: Redundancy in specifying data in processes Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object. I submitted a comprehensive document describing the situation to the issues@omg.org address, whithout any reaction since weeks. I am happy to send this document to the one assigned to this issue and discuss it. |
| Comments |
| Comment by Tammo van Lessen [ 25/Feb/10 08:56 AM ] |
| Frank's document attached. |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 02:58 PM ] |
| Co-Chairs moved to Ballot 11. |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:06 AM ] |
| Proposal: Address as part of example also showing WSDL and XSD artifacts. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:27 PM ] |
|
Matthias, can you make a comment with detailed information about the proposal. Text changes (if this is a fix), description of the reasons, etc.
This issue cannot be includes as-is in a ballot, it requires more detail Regards, |
| Comment by Ivana Trickovic [ 13/Apr/10 05:04 AM ] |
|
##Proposed Resolution: Defer
This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification. |
[BPMNFTF-517] [OMG 15049] Clarification of Temporal Sematics of Sequence Flow
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Fred Cummins | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: HP (Fred Cummins fred.cummins@hp.com)
******************************************************************************* Name: Fred Cummins Company: HP mailFrom: fred.cummins@hp.com Notification: Yes Specification: BPMN Section: General FormalNumber: dtc/09-08-14 Version: 2.0 Beta 1 RevisionDate: August 2009 Page: 19, 26, 27, 78, 98, 99, 100, 129, 130, 170, 172, 174, 199, 214, 215, 217, 221, 222, 225, 226, 235, 246, 253, 256, 257. 263, 267-276, 354, 390-408, 409, 433, 460, 464 Title: Clarification of Temporal Sematics of Sequence Flow Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: While tokens may help explain behavior, the specification should not rely on the concept of tokens to define the normative behavior of model elements. Sequence flows represent temporal constraints requiring that an "incoming" constraint be satisfied before a flow element can be executed. The specification should refer to the sequence of execution or the flow of control rather than the flow of tokens. While the specification explicitly says that tokens are a theoretical concept for explanation of behavior, the specification refers to the flow of tokens in many places. For example, the end event behavior is described as "The Process will be in a running state until all tokens are consumed." Since tokens are not required for compliance, the normative definitions of behavior should not be specified in terms of token flows but in terms of satisfaction of temporal constraints. Consistent use of temporal constraint semantics is importnant for specialization of processes (addition of intervening elements) and analysis of processes such as validation of compliance with a choreography. ------------- Proposal -------------- 2010-02-24 ---------------------------- ##Proposed Resolution: Close; No Change Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Feb/10 04:03 PM ] |
|
---------- Discussed during Conference Call on 2010-02-24 -----------------
Use of tokens for normative definition of semantics It is just terminology? The issue requests that spec text to be rewritten Use temporal constraints instead of tokens A lot of rewriting. What is the benefit? Can people not implement? Will implementations not interoperate? About 30 pages that will have to be changed. Effects explanations of temporal constraints to a subset of users We recognize that some end users might not understand the use of tokens But most will. It is more important that implementers understand. The FTF wants to use tokens as one way to describe semantics in the normative text. Other ways can be used to describe the semantics (outside of the spec) We propose: Close; no change |
| Comment by Stephen White [ 24/Feb/10 04:05 PM ] |
|
------------- Proposal -------------- 2010-02-24 ----------------------------
Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification ---------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 24/Feb/10 04:05 PM ] |
| New Proposed Resolution |
[BPMNFTF-516] [OMG 15045] ResourceParameter::type attribute should be of type ItemDefinition, not Element
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann matthias.kloppmann@de.ibm.com)
******************************************************************************* Name: Matthias Kloppmann Company: IBM mailFrom: matthias.kloppmann@de.ibm.com Notification: Yes Specification: BPMN 2.0 Section: 8.3.16 Resources FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 98 Title: ResourceParameter::type attribute should be of type ItemDefinition, not Element Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Table 8.59 currently describes that the type of the "type" attribute of ResourceParameter is "Element". For consistency with other similar attributes, the type should really be "ItemDefinition". -----Proposal---------------- 2010-02-24 ------------------------- ##Proposed Resolution: Fixed (a) Table 8.59, page 98 (128 pdf), second row, first column: Replace "element" with "itemDefinition" (b) Update Figure 8.44, page 97 (127 pdf) to reflect the above change (c) Update XSD schema to reflect the above change ----------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Feb/10 03:52 PM ] |
|
-----Proposal---------------- 2010-02-24 -------------------------
(a) Table 8.59, page 98 (128 pdf), second row, first column: Replace "element" with "itemDefinition" (b) Update Figure 8.44, page 97 (127 pdf) to reflect the above change (c) Update XSD schema to reflect the above change ----------------------------------------------------------------------------- |
| Comment by Stephen White [ 24/Feb/10 03:53 PM ] |
| New Proposed Resolution |
[BPMNFTF-515] [OMG 15044] Parallel Event Based Gateway capability is hidden away
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.5.6 FormalNumber: dtc/2009-08-14 Version: 2.0 Beta RevisionDate: 08/14/2009 Page: pg 306 Title: Parallel Event Based Gateway capability is hidden away Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Section 10.5.6 (pg 306) talks about the Parallel Event Based Gateway and introduces new notation for it (Figure 10.115). But that concept and notation doesn't appear in other parts of the document. I would expect to see it in Section 7.2.2 (pg 56) and also in Figure 10.99 (pg 294). Otherwise, it would be extremely easy to miss this new capability. |
| Comments |
| Comment by Conrad Bock (NIST) [ 20/Apr/10 01:05 PM ] |
|
-----------Proposal----------------Apr 20, 2010---------------------------
##Proposed Resolution: Fixed In Table 7.2 (BPMN Extended Modeling Elements): - in the row with left column containing "Gateway Control Types", in the right column, to the right of the symbol for Event-Based, insert the symbol in Figure 10.115 (Parallel Event-Based Gateway to start a Process). - in the row with left column containing "Event-Based": - in the middle column, at the end, add the paragraph: Parallel Event-based gateways start a new instance of the process. - in the right column, at the bottom, insert a copy of the subfigure at the top of the column, except replace the diamond shape with the symbol in Figure 10.115 (Parallel Event-Based Gateway to start a Process), and remove the rounded rectangle and the arrow going out of it. In Figure 10.99 (The Different types of Gateways), to the right of the symbol for Event-Based, insert the symbol in Figure 10.115 (Parallel Event-Based Gateway to start a Process). |
[BPMNFTF-514] [OMG 15043] Multi-language labels for diagram elements
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | General, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Signavio (Gero Decker, gero.decker@signavio.com)
Specification: BPMN Section: -- FormalNumber: -- Version: -- RevisionDate: -- Page: -- Title: Multi-language labels for diagram elements Nature: Enhancement Severity: Significant Description: Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label. Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram) ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 11/Feb/10 12:36 PM ] |
|
From my perspective, this is a good feature, that could be included in a subsequent FTF/RTF. I would not discard it.
So, according to my understanding of OMG guidelines, I would propose to defer this issue. |
| Comment by Mariano Benitez (Oracle) [ 11/Feb/10 12:37 PM ] |
|
New Proposed Resolution: Deferred
As of my previous comment, I propose to defer this issue. |
[BPMNFTF-513] [OMG 15042] The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Falko Menge |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.2.4 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 182-183 Title: The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading Nature: Revision Severity: Critical test: 3qw8 B1: Report Issue Description: The example is provided to showcase human performers. Figure 10-22 incorrectly depicts a pool in a process diagram. It should be a lane named: Buyer. (i.e. remove the line seperating the label Buyer from its content) Table 10-19 provide an incorrect serialization. There should be a laneset element with a single lane named : Buyer. The use of the string Buyer as process id is also very misleading. This example should be completly revalidated for correctness....critical because it is the only example of a serialization of the semantic of a process. ##Proposed Resolution: Duplicate This issue is addressed by |
| Comments |
| Comment by Falko Menge [ 20/Apr/10 04:52 PM ] |
|
----Proposal---------------- 04/20/2010 -------------------------
##Proposed Resolution: Duplicate This issue is addressed by Issue 15163 (http://www.osoa.org/jira/browse/BPMNFTF-578). |
| Comment by Falko Menge [ 20/Apr/10 04:52 PM ] |
| New Proposed Resolution |
[BPMNFTF-512] [OMG 15040] Add an attribute that can identify a rulebase/rule engine for Business Rule Task
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Tammo van Lessen | Assigned To: | Tammo van Lessen |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Tammo van Lessen Company: Intalio mailFrom: tammo@intalio.com Notification: Yes Specification: Business Process Model and Notation (BPMN) Section: 10.2.3 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 141, 142 Title: Add an attribute that can identify a rulebase/rule engine for Business Rule Task Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently, a Business Rule Task has only an "implementation" attribute that is used to identify the technology used to interact/communicate with a rule engine (e.g. Web Service or any other protocol). However, there is no possibility to identify to which rule engine the data should be sent nor which rule set should be processed. I believe that this information is crucial from a vendor perspective. My suggestion is to add an anyURI-attribute called "ruleSet" (perhaps there is more generic term). The attribute's value can be resolved at runtime/deployment time by BPMS to identify both, rule engine and ruleset or other rule engine specific settings. ##Proposed Resolution: Close, no change Since the business rule task is underspecified, vendor specific extensions are needed anyway. So there is no real value in adding any additional attribute, since interoperability will not be possible. |
| Comments |
| Comment by Falko Menge [ 15/Feb/10 11:50 AM ] |
|
1.) How can the facts be defined, on which the rules will be applied?
Explicitly using data objects? Or does the rule engine have implicit access to all process variables? Do we need to mention this in the specification? 2.) How does this issue relate to |
| Comment by Tammo van Lessen [ 17/Feb/10 08:54 AM ] |
|
It is not related to |
| Comment by Tammo van Lessen [ 02/Mar/10 04:42 AM ] |
| Checked that with Kris Verlaenen, a Redhat developer who is implementing BPMN 2.0 on top of Drools and hence knows both worlds. He could confirm this issue. For that purpose they have introduced a proprietary attribute called "ruleFlowGroup". |
| Comment by Tammo van Lessen [ 02/Mar/10 05:14 AM ] |
|
-------------- Proposal ----------- 2010-03-02 -----------------------------------
##Proposed Resolution: Fixed Summary: Introduce a new attribute ("rulebase") to "Business Rule Task" that helps identifying the rule engine, ruleset, knowledge base etc. via an URI pointing to an abstract artifact that can be resolved by the runtime environment. Changes: - Update Figure 10.10: Add "rulebase : String" to BusinessRuleTask - Update Table 10.11: Add a row. Column 1: "rulebase : String", Column 2: "This attribute specifies the rule base this task is referring to in an abstract manner. Valid values are URIs that identify a set of rules within a Business Rules Engine. The URI MUST be resolved by BPMN runtime environments to concrete implementations." |
| Comment by Tammo van Lessen [ 02/Mar/10 05:33 AM ] |
|
In addition to my last comment, tBusinessRuleTask in Semantic.xsd should read as follows:
<xsd:complexType name="tBusinessRuleTask"> <xsd:complexContent> <xsd:extension base="tTask"> <xsd:attribute name="rulebase" type="xsd:anyURI" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comment by Tammo van Lessen [ 18/Mar/10 07:19 AM ] |
|
Although I still believe it would improve the spec, we agreed in yesterday's sub-team call to close this issue. The decisive argument was: Since the business rule task is underspecified, vendor specific extensions are needed anyway.
Proposed resolution: Close, no change. |
| Comment by Tammo van Lessen [ 18/Mar/10 07:20 AM ] |
| New proposed resolution |
| Comment by Tammo van Lessen [ 18/Mar/10 07:24 AM ] |
| proposalScheduledForBallot10 |
[BPMNFTF-511] [OMG 15038] Confusing semantics for Terminate End Event
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Robert Shapiro | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Robert Shapiro Company: Global 360 mailFrom: robert.shapiro@global360.com Notification: Yes Specification: Business Process Modeling Notation Section: 10.4.3,,14.4.6 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 224, 407 Title: Confusing semantics for Terminate End Event Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The spec has two confusing statements for Terminate End Event: In section 10.4.3: Terminate: This type of End indicates that all activities in the Process should be immediately ended. This includes all instances of Multi-Instances. The Process is ended without compensation or event handling. In section 14.4.6: Sub-process level end events: For a "terminate" End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated. ##Proposed Resolution: Fixed Terminate End Events only interrupt the specific instance of a given Process level (Process or Sub-Process). Any other parallel instances or higher-level instances are not affected. (a) Section 14.4.6, Sub-Section "Process level end events": Replace the first sentence with the following: "For a "terminate" End Event, the Process instance is abnormally terminated—no other ongoing Process instances are affected." (b) 14.4.6, Sub-Section "Sub-Process level end events": Replace the first paragraph with the following: "For a "terminate" End Event, the Sub-Process instance is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:44 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-510] [OMG 15031] BPMN CMOF File problems
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 13 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Maged Elaasar |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
2010-05-04.zip
|
| Description |
|
Specification: BPMN v2.0 Beta-1 (CMOF files)
Title: BPMN CMOF File problems ##Source: NIST (Ed Barkmeyer, edbark@nist.gov) Summary: The Beta-1 CMOF files on the server (spec/BPMN/2.0/20090501/cmof.xmi http://www.omg.org/spec/BPMN/2.0/20090501/cmof.xmi, spec/BPMN/2.0/20090501/Infrastructure.xmi http://www.omg.org/spec/BPMN/2.0/20090501/Infrastructure.xmi, spec/BPMN/2.0/20090501/Semantic.xmi http://www.omg.org/spec/BPMN/2.0/20090501/Semantic.xmi) are invalid in several ways: (1) The schemaLocation for the UML Infrastructure schema is an EMF URI that returns Error 404. The only elements actually used in the BPMN model are the primitive types. It is preferable to provide only the standard UML URI and assume that any CMOF implementation will have a known source for it. (2) The modularization of the Infrastructure Package makes no sense.The Infrastructure Package must import Core::Foundation in order to define the associations from Definitions to RootElements, Relationships, and Extensions. Otherwise those data types are undefined. And in the current model, only the association ends owned by Definitions are in the Infrastructure Package; the associations themselves and the non-navigable ends are owned by the Foundation Package. It is not clear what religious motive caused Infrastructure to be removed from the Core Package in the first place. It is documented as part of the Core in the specification. Definitions is a subclass of BaseElement and inheriting the identifier documentation is important. If you really want to separate Definitions (and Imports) for some reason, then you need to split Definitions into an Infrastructure version containing only the properties that are wholly contained in the Infrastructure package and a Core version that has the properties that bind Definitions to Foundation elements, including the generalization, and then packageMerge Infrastructure into Core. But then the "reusable" thing in the Infrastructure package has neither a formal id, nor any associated text.] (3) Foundation should import the "cmof" Package (which should really be the OMG standard reference) to define Element, for external Relationships and Extensions. (4) Infrastructure should import the "interchange" Package that "defines" Diagram, and the "interchange" module should define the class Diagram, not the class NotInSpec. I realize that this is a fudge, but the existing nonsense causes Definitions:diagrams to be a model inconsistency when loading the XMI file into a CMOF repository. Yes, it is difficult to get a correct CMOF file out of the EMF libraries, or any UML tool. But it is the only form on the OMG server that can be loaded into a model library for integration with other cmof:Element objects (e.g., from UML or UPDM or SysML or BMM models).The XML schemas are worthless for this purpose. So, if you want Extension to work, fix the CMOF file. ##Proposed Resolution: Fixed All machine-readable files are included in document DTC/2010-05-04, including CMOF files. The zip file with these files is attached: http://www.osoa.org/jira/secure/attachment/10762/2010-05-04.zip There are several sections under chapter 16 (chapter 15 of the final draft) that indicate the location of machine-readable files. Introduce a new section before Section 16.2 XSD - Section 15.2 Machine readable files BPMN 2.0 machine readable files, including XSD, XMI and XSLT files can be found in OMG Document DTC/2010-05-04, which is a zip file containing all the files. XSD files are found under the XSD folder of the zip file, and the main file is XSD/BPMN20.xsd. XMI files are found under the XMI folder of the zip file, and the main file is XSD/BPMN20.cmof. XSLT files are found under the XSLT folder of the zip file. - Section 16.2 XSD Remove the first two paragraphs (starting "The BPMN 2.0 XSD"). - Section 16.3 XMI Remove the first paragraph (starting "The BPMN 2.0 XMI"). - Section 16.4 XSLT Transformation between XSD and XMI Replace the paragraph with the following text: - The XSLT transformation from XSD to XMI is in the file XSLT/BPMN20-ToXMI.xslt - The XSLT transformation from XMI to XSD is in the file XSLT/BPMN20-FromXMI.xslt |
| Comments |
| Comment by Ivana Trickovic [ 11/Mar/10 03:53 AM ] |
|
As per March F2F Meeting:
- To be assigned to Maged. This is an action item for the FTF and not a technical issue. CMOF will be provided after May 9. |
| Comment by Ivana Trickovic [ 11/Mar/10 07:28 AM ] |
|
As per March F2F Meeting:
- To be assigned to Maged. This is an action item for the FTF and not a technical issue. CMOF will be provided after May 9. |
| Comment by Mariano Benitez (Oracle) [ 17/May/10 05:54 PM ] |
| This zip file is a draft containing all machine readable files (XSD, XMI, XSLT). |
| Comment by Mariano Benitez (Oracle) [ 19/May/10 03:45 PM ] |
|
A note in the final report will be added to this issue with the following text, please advice/correct.
MAriano ----------------------------- Note (not part of issue resolution): XMI files included in the submission are: - Normative: Merged CMOF (included in document 2010-05-04) BPMN20.cmof BPMNDI.cmof DI.cmof DC.cmof - Non-normative: Structured CMOF (included in document 2010-05-15) Semantic.cmof Infrastructure.cmof |
| Comment by Falko Menge [ 08/Jun/10 01:46 PM ] |
|
spec-May24-review
All three zip files provided in http://www.omgwiki.org/bpmn2.0-ftf/doku.php?id=public:report contain hidden files presumably created by Mac OS X, which have not been part of the zip file attached to this issue. Proposal: Remove directories called '__MACOSX' and files called '.DS_Store' from all three zip files. |
[BPMNFTF-509] [OMG 15030] Ambiguous statements about Sequence Flow
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 211 Title: Ambiguous statements about Sequence Flow Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event."Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:34 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:09 AM ] |
| Move on ballot #11 to remove ambiguous specification text. |
[BPMNFTF-508] [OMG 15029] Mutiple depictions of a single semantic element
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.3 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 211 Title: Mutiple depictions of a single semantic element Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: When a single semantic element has multiple depictions (e.g. DataObjects), this forces the requirement for the target and source information to be duplicated in the DI schema in oder to know where to draw the association (i.e to which instance). In the case of DatStore, the solution was to have only one semantic element dataStore and have dataSoreRefs as depictable duplicate elements. Maybe the same could be explored for DataObjects ##Proposed Resolution: Duplicate The resolution for Issue 15080 ( |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:46 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 18/Mar/10 08:46 PM ] |
| The resolution of JIRA 540 may resolve this issue |
[BPMNFTF-507] [OMG 15028] Depictable element without a reference semantic element
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange, Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Denis Gagne |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 11 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 328-341 Title: Depictable element without a reference semantic element Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: When a Depictable element does not have a semantic element to reference, this forces the DI to duplicate target and source information in the schema in order to properly depict such elements. This is the case for at least the Conversation links which are depicted (e.g. figure 11-11)in conversation diagrams but do not have a semantic element. ##Proposed Resolution: Close, No Change This issue is addressed by the porposal at issue |
| Comments |
| Comment by Denis Gagne [ 15/Apr/10 09:50 AM ] |
|
##Proposed Resolution: Close, No Change
This issue is addressed by the porposal at issue |
[BPMNFTF-506] [OMG 15027] Table 10-4 page 162 List of possible states of an Activity instance
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-activities.doc
10_process-general.doc
|
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.2 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: Table 10-4 page 162 Title: Table 10-4 page 162 List of possible states of an Activity instance Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The enumeration of possible states for an Activity does not reflect the possible states as per the execution semantics provided in chapter 14 on the state diagram figure 14-2 ##Proposed Resolution: Fixed > Section 10. Process Table 10.2 - Process Instance Attributes Change row: state Original Attribute Name state: string = none {none | ready | active | cancelled | aborting | aborted | completing | completed} Description/Usage The current state of this Process instance. Proposal Attribute Name state: string = none Description/Usage The current state of this Process instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values. > Section 10.2 Activities Table 10.2 - Activity instance attributes Change row: state Original Attribute Name state: string = none {none | ready | active | cancelled | aborting | aborted | completing | completed} Description/Usage The current state of this activity instance. Proposal Attribute Name state: string = none Description/Usage The current state of this activity instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values. |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 03:29 AM ] |
|
As per March F2F Meeting:
Agreed to make the following changes: - Remove enumerations in tables 10.2 - Process Instance Attributes and 10.4 - Activity instance attributes - In the attribute description add a reference to the states in activity state diagram (section 14.2.2 in Beta 1) |
| Comment by Ivana Trickovic [ 22/Mar/10 06:02 PM ] |
| proposalScheduledForBallot11 |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:53 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:53 AM ] |
|
> Section 10. Process
Table 10.2 - Process Instance Attributes Change row: state Original Attribute Name state: string = none {none | ready | active | cancelled | aborting | aborted | completing | completed} Description/Usage The current state of this Process instance. Proposal Attribute Name state: string = none Description/Usage The current state of this Process instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values. > Section 10.2 Activities Table 10.2 - Activity instance attributes Change row: state Original Attribute Name state: string = none {none | ready | active | cancelled | aborting | aborted | completing | completed} Description/Usage The current state of this activity instance. Proposal Attribute Name state: string = none Description/Usage The current state of this activity instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values. |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:53 AM ] |
| New Proposed Resolution |
[BPMNFTF-505] [OMG 15007] How to represent Activities that might fit in more than one Lane?
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White, wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: Section 10 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: many Title: How to represent Activities that might fit in more than one Lane? Nature: Clarification Severity: Significant Description: Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen? |
| Comments |
| Comment by Rob Bartel [ 29/Jan/10 10:28 AM ] |
| One way existing tools represent this is to allow an element to span lanes graphically. If this is allowed, however, there also should be an attribute that will exclude some crossed lanes from the element because it is not generally possible to lay out the lanes and the elements such that all lanes that an activity should be displayed in are adjacent. |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 07:10 PM ] |
|
The other option is to allow a Lane to represent multiple things. For example, a Lane for 'Manager and Reviewer'.
Spanning lanes doesn't sound scalable. As stated, it's not possible to apply that approach in all cases. |
| Comment by Mariano Benitez (Oracle) [ 05/Feb/10 07:06 AM ] |
|
ok, I see 2 potential issues here:
1) activities in the metamodel can belong to multiple lanes, there is no restriction that any activity can belong to more than one lane of the same laneset. This means that we can potentially have to render visual models with this situation. 2) I don't think there's an elegant way to visualize the same activity in multiple lanes. The paradigm we've chosen (the visual swimlanes) is good for exclusive segregation... (well, from my point of view) |
| Comment by Suzette Samoojh (IBM) [ 05/Feb/10 10:11 AM ] |
|
Precisely. Which is why the only solution that I can think of is to establish mutually exclusive lanes. If Activity 1 is associated with the Manager resource, and Activity 2 is associated with both the Manager resource and the Reviewer resource, then we'd create two exclusive swimlanes:
- Swimlane for activities associated with "Managers" only: Activity 1 goes there - Swimlane for activitiies associated with both "Managers and Reviewers": Activity 2 goes there But I know this is far from ideal. So would love to hear better alternatives. |
| Comment by Stephen White [ 18/Mar/10 08:49 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:08 AM ] |
| Update the proposed issue resolution to say that this is a request for an enhancement, but those not represent an implementation issues. So the FTF agreed to defer it and leave this issue in the wish list for the RTF. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:26 AM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-504] [OMG 14966] Clarify "Instance of this Conversation."
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: Section 8.3.3 FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: 67 Title: Clarify "Instance of this Conversation." Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The text uses the term "instance of this Conversation." This should be clarified. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:49 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:07 AM ] |
| Move on ballot #11 to remove ambiguous specification text. |
| Comment by Ivana Trickovic [ 19/Apr/10 07:38 AM ] |
| I could not reproduce the problem in Beta 1, draft 1, so I suggest to close the issue with no changes to the specification. Steve, if you think this is still a problem please add page numbers. |
| Comment by Ivana Trickovic [ 19/Apr/10 07:39 AM ] |
|
##Proposed Resolution: Closed, no change
The problem could not be reproduced so the proposal is to close this issue with no changes to the specification. |
[BPMNFTF-503] [OMG 14965] Change plural "flow" to "flows"
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: Throughout FormalNumber: dtc/2009-08-14 Version: Beta RevisionDate: Aug 2009 Page: many Title: Change plural "flow" to "flows" Nature: Clarification Severity: Minor Description: BPMN has used Message Flow and Sequence Flow to refer to the terms for both singular and plural uses. In the interest of reducing confusion, change the plural forms to Message Flows and Sequence Flows. -------- New Proposed Resolution ---------- 2010-01-14 -------------------------------- ##Proposed Resolution: Fixed In all cases where the word "flow" is used in plural form, change the word to "flows." This would include all plural instances Sequence Flow and Message Flow. Note: there will be change tracking markings, but there will not be an annotation for each occurrence of this change. ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 14/Jan/10 11:29 AM ] |
|
-------- New Proposed Resolution ---------- 2010-01-14 --------------------------------
In all cases where the word "flow" is used in plural form, change the word to "flows." This would include all plural instances Sequence Flow and Message Flow. Note: there will be change tracking markings, but there will not be an annotation for each occurrence of this change. ----------------------------------------------------------------------------------------------------------- |
[BPMNFTF-502] [OMG 14932] Correlation key property values from process instances
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: Yes Specification: BPMN 2 Beta 1 Section: Interactions FormalNumber: dtc/2009-08-14 Version: RevisionDate: Page: Title: Correlation key property values from process instances Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: How are correlation key property values pulled from a process instance?Correlation Property Retrieval Expression only maps the contents of themessage instance to a key instance, not to the process instance. ##Proposed Resolution: Close, No Change * Added improved description as part of * Correlation key properties are only pulled from a message, on behalf of a process instance (via the associated conversation that the send/receive task or message event belongs to), and thus assigned as a key to the process instance. Thus nothing needs to be added. |
| Comments |
| Comment by Tammo van Lessen [ 10/Mar/10 05:25 AM ] |
|
While edit, please also address the following issue:
For both, key-based and context-based correlation types, not only send and receive tasks are capable to populate CorrelationKey instances. Message events must also be considered. Search for "At runtime the first Send Task or Receive Task in a Conversation populates..." on page 67 in beta1 and "the established mechanism of having the first Send Task or Receive Task populate..." on page 69 and add throwing and catching message events accordingly. |
| Comment by Ivana Trickovic [ 10/Mar/10 08:04 AM ] |
|
As per March F2F Meeting:
- Probably this is part of - Probably just a better description is needed. |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:21 AM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:24 AM ] |
|
* Added improved description as part of * Correlation key properties are only pulled from a message, on behalf of a process instance (via the associated conversation that the send/receive task or message event belongs to), and thus assigned as a key to the process instance. Thus nothing needs to be added. Proposal: Close, superseded by |
| Comment by Conrad Bock (NIST) [ 12/Apr/10 09:02 AM ] |
|
Matthias,
This one is about how values are pulled from the process instance (to compare to the key property values), rather than how they're pulled form the message instance. For example, we can't capture that a particular key property is compared to a particular process property or data object. Conrad |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 12:49 PM ] |
|
Conrad,
I understand what you're asking -- however, matters are different: There are no properties being pulled "from the process". The fact that a message targets a particular process instance (either by creating it during initial receive, or by being sent from it) associates its keys with that process instance. There is no need to ever pull any data "from the process". Actually, correlation would work without any data objects being defined in the process, as it is entirely depending on message payload data only. So, for example: An initiating message createOrder is sent, containing customerID=42 (all keys assumed to be properly defined as correlation keys). Thus, a new instance is created, and the correlation key "customerID" with value "42" assigned to it. No suppose the process creates a new order, and responds to its caller with a message confirmOrder containing orderID=67. By sending the response, the correlation key "orderID" with value "67" will be assigned to the process instance. Now assume an order cancellation message with orderID=67 is sent. All active process instances will be searched for correlation keys where the "orderID" has a value of "67". There may be at most one waiting with that combination, and the message is routed to it. Nowhere is ever a correlation key "pulled from the process", they are always pulled from messages and automatically associated with the process. -Matthias |
| Comment by Conrad Bock (NIST) [ 19/Apr/10 08:51 AM ] |
|
Matthias,
> Nowhere is ever a correlation key "pulled from the process", they are > always pulled from messages and automatically associated with the > process. I see, thx for the example. But how would this apply to subscription? Then the process is providing the data matched to the keys, as I understand it. Also wouldn't say this issue is duplicate with Conrad |
[BPMNFTF-501] [OMG 14921] Inconsistent/confusing statements around CallActivities and IOSpecifications
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 2009-08-14 Page: 166, Title: Inconsistent/confusing statements around CallActivities and IOSpecifications Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Does a CallActivity own data inputs, outputs, etc? And when you draw a data association to/from a CallActivity, is the data association connecting to/from data inputs and outputs of the CallActivity or data inputs and outputs of the CallableElement? PDF pg 196 states that "Call Activities must not define their own data inputs, InputSets, and outputs, OutputSets but use the data inputs, InputSets, and outputs, OutputSets defined in the referenced CallableElement" This reads like CallActivities don't own data inputs/outputs of their own. But then PDF pg 225 states that "... the data inputs and outputs of the Call Activity must match with the data inputs, inputsets and outputs, outputsets defined in the callable element". This explicitly states that a CallActivity does own data inputs, etc. So then what's the meaning behind the statements on PDF pg 196? ##Proposed Resolution: Fixed a) in section 10.2.6 Call Activity, replace the following paragrah: "Since Call Activities rely in the CallableElement being invoked (see Figure 10.40), Call Activities must not define their own data inputs, InputSets, and outputs, OutputSets but use the data inputs, InputSets, and outputs, OutputSets defined in the referenced CallableElement." with this one: "A CallActivity must fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.40). This means that the elements contained in the CallActivity's InputOutputSpecification must exactly match the elements containes in the referenced CallableElement. This includes DataInputs, DataOutputs, InputSets and OutputSets." b) in section 10.3.1 Data Modeling (Call Activity Mapping) replace the following paragraph: "Since Call Activities rely in the callable element being invoked, the data inputs and outputs of the Call Activity must match with the data inputs, inputsets and outputs, outputsets defined in the callable element. The data inputs and outputs of the Call Activity are mapped to the corresponding data inputs and output of the Callable Element without any explicit data association." with this one: "The DataInputs and DataOutputs of the CallActivity are mapped to the corresponding elements in the CallableElement without any explicit data association." |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 12:53 PM ] |
|
See also related issue The schema is designed with the assumption that CallActivities do own data inputs/outputs. But the spec text is open to interpretation (as evidenced by I think this is important to address. |
| Comment by Ivana Trickovic [ 10/Mar/10 08:34 AM ] |
|
As per March F2F Meeting:
- Agreed that the following sentence shall be fixed: PDF pg 196 "Call Activities must not define their own data inputs, InputSets, and outputs, OutputSets but use the data inputs, InputSets, and outputs, OutputSets defined in the referenced CallableElement" It should state that Call Activity defines its own data inputs, etc but they MUST be a mirror image of the data inputs, etc. defined in the referenced CallableElement. - Sentence on page 225 is correct. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:59 PM ] |
| proposalScheduledForBallot11 |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 10:05 AM ] |
| New Proposed Resolution |
[BPMNFTF-500] [OMG 14919] Exclusive Gateway (missing sub-heading)
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Atos Origin(Lyndon Roy, lyndon.roy@atosorigin.com)
Specification: Business Process Model and Notation (BPMN) Section: 14.3 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 398 (428) Title: Exclusive Gateway (missing sub-heading) Nature: Revision Severity: Minor Description: I believe that there is a sub-heading missing between sections 14.3.1 and 14.3.2.; the missing sub-heading relates to the Exlusive gateway description found on pages 399-400 (429-430). The text of the sub-heading appears after table 14.1 (the text is 'Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)') but it hasn't been tagged as a sub-heading. ------------------------ New Proposed Resolution ----------- 2010-01-22 ---------------------------- ##Proposed Resolution: Fixed Section 14.3.1, page 398 (428 pdf), last sentence on page: Reformat sentence to make it a level 3 heading ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 22/Jan/10 01:07 PM ] |
|
One of the sentences lost its formating and needs to be reset to heading level 3
------------------------ New Proposed Resolution ----------- 2010-01-22 ---------------------------- Section 14.3.1, page 398 (428 pdf), last sentence on page: Reformat sentence to make it a level 3 heading ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-499] [OMG 14890] Ambiguity when multiple message flows associated with a choreography task
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Gary Brown | Assigned To: | Gary Brown |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: RedHat (Gary Brown gbrown@redhat.com)
Subject: Ambiguity when multiple message flows associated with a choreography task Spec: BPMN2-FTF If a choreography task is associated with more than two message flows, or with two message flows that are in the same direction (i.e. same sending and receiving participants), then the ordering of the message flows is ambiguous. If the choreography is ambiguous, and process models associated with each participant in the choreography are independently developed, it may mean that the resulting process models may not be able to interact correctly. There are a couple of possible solutions: 1) Only permit a choreography task to have a max of two message flows. If two are defined, then they must be in opposite directions. 2) If more than two message flows are defined, then an MEP (and possibly other additional supporting information) needs to be specified that makes the ordering explicit. For example, request/response/fault MEP could be specified, where only one message flow could be in one direction (i.e. the request), and all others are in the opposite direction - and the semantics would be that only one of the 'response' message flows could occur. Note: not sure whether it would be necessary to distinguish those flows as one normal response and remaining being fault responses - may be necessary to map to standard rpc pattern. -------- New Proposed Resolution ---------- 2010-01-10 -------------------------------- ##Proposed Resolution: Fixed PDF page 360: (a) Replace: "A single Choreography Task can be used for one (1) or more Messages. Most of the time there will be one (1) or two (2) Messages for a Choreography Task." With: "A single Choreography Task can be used for one (1) or two (2) Messages, with at most one (1) Message per Participant." PDF page 388: (b) Change schema for tChoreographyTask "<xsd:element name="messageFlowRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/>" so that maxOccurs is 2. ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Gary Brown [ 08/Jan/10 06:05 AM ] |
|
At present, I believe the most complex MEP that needs to be handled is the req, resp + zero or more faults. If faults are handled as intermediate events attached to the Choreography Task, then the only Message Flows that need to be directly attached to the Choreography Task are the request and response.
Using this approach, then the Choreography is not ambigious, and precisely defines how each participant process model needs to be behave. So the proposal is to only permit a max of two Message Flows per Choreography Task, which must be in opposite directions - i.e. one inbound and one outbound. PROPOSAL DETAILS: ================= PDF page 360: Replace: "A single Choreography Task can be used for one (1) or more Messages. Most of the time there will be one (1) or two (2) Messages for a Choreography Task." With: "A single Choreography Task can be used for one (1) or two (2) Messages, with at most one (1) Message per Participant." PDF page 388: Change schema for tChoreographyTask "<xsd:element name="messageFlowRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/>" so that maxOccurs is 2. |
| Comment by Gary Brown [ 11/Jan/10 09:19 AM ] |
|
New Proposed Resolution
(as above) |
| Comment by Mariano Benitez (Oracle) [ 12/May/10 04:45 PM ] |
|
Spec-Draft3-review
The proposal part (a) - only part of the original text has been replaced with only part of the defined replacement text. The proposal part (b), which relates to updates in the schema, has not been applied in the Semantic.xsd. (reported by Gary Brown) |
| Comment by Suzette Samoojh (IBM) [ 17/May/10 11:34 AM ] |
| Done. Semantic.xsd corrected. |
[BPMNFTF-498] [OMG 14880] INCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Atos Origin (Lyndon Roy, lyndon.roy@atosorigin.com)
Specification: Business Process Model and Notation (BPMN) Section: Annex C: Glossary FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 457-465 (487-495) Title: iNCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY Nature: Revision Severity: Significant Description: Glossary in Annex C contains a number of definitions of, and references to, workflow patterns that were incorrect in version 1.0 of the spec and are still incorrect in version 2.0. For example, see the following definitions:Deferred Choice references workflow pattern #17 actually Deferred Choice is pattern #16;Discriminator references workflow pattern #8 actually Discriminator is pattern #9;Implicit Termination references workflow pattern #12 actually Implicit Termination is pattern #11 Also the URL for these workflow patterns has changed (All pages from 'tmitwww.tm.tue.nl' have moved to the server 'is.ieis.tue.nl' - although the latest patterns can actually be found at http://www.workflowpatterns.com/). May I suggest that the entire contents of the Glossary are reviewed against the latest set of workpatterns (http://www.workflowpatterns.com/documentation/documents/BPM-06-22.pdf) and ensure that the correct pattern numbers are used. I would also like the glossary to be extended to cover the extra workflow patterns that have been defined beyond van der Aalst's original 20 (or 21 if you include pattern #9a)and that can can be implemented using BPMN notation - (www.workflowpatterns.com/documentation/documents/BPM-06-17.pdf might give useful guidance for this (even though it relates to BPMN v1)). ------------------------ New Proposed Resolution ----------- 2010-01-22 ---------------------------- ##Proposed Resolution: Duplicate The resolution of issue 14778 (JIRA ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 22/Jan/10 01:13 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-22 ----------------------------
Close; Duplicate. This issue is a duplicate of OMG Issue 14778 (JIRA 486) ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-497] [OMG 14879] The specification should clearly state what visual features are available for extensions and which are restricted to the core spec
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Mariano Benitez Company: Oracle mailFrom: mariano.benitez@oracle.com Notification: No Specification: BPMN 2.0 Section: 13 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 361 Title: The specification should clearly state what visual features are available for extensions and which are restricted to the core spec Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use. We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users). For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 02:47 PM ] |
| New Proposed Resolution |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 02:49 PM ] |
|
##Proposed Resolution: Defer
It would be important for the spec to clearly specify the limits where graphical extensions can be added, and what is exclusive to the specification. It is not important right now, but I think we need to fix this. specially looking forward. So I propose to defer the issue. |
[BPMNFTF-496] [OMG 14878] Visibility and permissions for Data Objects and Properties must be described
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Mariano Benitez Company: Oracle mailFrom: mariano.benitez@oracle.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 181 Title: Visibility and permissions for Data Objects and Properties must be described Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: We should be clear in the spec the places/actions that can read and write on a DataObject or Property. For example: is it valid to update an activity property in another activity? We should be extensive in this, otherwise it will be left to vendor interpretation and this can create confusion. This was discussed in the BPMN 2.0 FTF in December 2009. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
| Comment by Mariano Benitez (Oracle) [ 17/Mar/10 11:27 AM ] |
|
##Proposed Resolution: Close, No Change
Under section 10.3.1 Data Modeling, paragraphs name "Lifecycle and Visibility" clearly defines the visibility and permissions for Data Object and Properties. Hence, this issue is already answered in the specification, and no change is required. |
| Comment by Mariano Benitez (Oracle) [ 17/Mar/10 11:27 AM ] |
| New Proposed Resolution |
[BPMNFTF-495] [OMG 14877] Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situations
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Unassigned |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Mariano Benitez Company: Oracle mailFrom: mariano.benitez@oracle.com Notification: No Specification: BPMN 2.0 Section: 14.2 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 392 Title: Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situations Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Does it make sense to describe the runtime behaviour of updating DataObjects and/or Properties by different executions? Should we leave this up to interpretations by implementers? Should we describe the expected behaviour or multiple executions updating the same DataObject/Property. This is specially important for multi-instance activities ##Proposed Resolution: Closed, Out Of Scope This is considered to be an enhancement. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:16 PM ] |
|
As per March F2F Meeting:
- This is considered to be an enhancement. - The proposal is to close (out of scope) the issue with no changes to the specification. |
[BPMNFTF-494] [OMG 14876] UML interface operations do not match BPMN interface operations
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration, SoaML |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
Specification: BPMN 2.0 Section: 8.4 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 108 Title: UML interface operations do not match BPMN interface operations Nature: Revision Severity: Critical Description: Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation. But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier.This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same. So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out.We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:09 PM ] |
|
As per March F2F Meeting:
- There is agreement that BPMN Operation shall not be changed to RPC style - Examples/guidelines for implementers should be developed. Examples should illustrate BPMN->WSDL RPC mapping - This issue is not critical. Change the priority to minor |
| Comment by Stephen White [ 24/Mar/10 07:46 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:06 AM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. (E.g. See the notes from the F2F.) |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:25 AM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-493] [OMG 14869] Does CallChoreography need a MessageFlowAssociation?
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 12 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 325 Title: Does CallChoreography need a MessageFlowAssociation? Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: Choreographies contain Message Flow. The CallChoreographyActivity will call another Choreography or a GlobalChoreographyTask, both of which have there own Message Flow. There are similar relationships to Participant. A CallChoreographyActivity has a ParticipantAssociation, so it should also have a MessageFlowAssociation or should not have the ParticipantAssociation. ##Proposed Resolution: Close; No Change The Message Flow within the called Choreography will not be used or interact within the calling Choreography, so no mapping is required. Thus, there is no change required to the specification. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:54 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 05/Apr/10 06:19 PM ] |
| Resolution explanation updated on 2010-04-05 |
[BPMNFTF-492] [OMG 14863] Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Rouven Day (SAP) | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Rouven Day Company: SAP AG mailFrom: Rouven.Day@sap.com Notification: Yes Specification: BPMN 2.0 Section: 8.3.15 FormalNumber: dtc/2009-08-14 Version: Beta 1 RevisionDate: 2009-08-14 Page: 93 Title: Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: In the class diagram for Participant (Figure 8.40 - The Participant Class Diagram) the reference to a Process is missing.In the list of attributes it is available but not in the diagram.Since this is a very prominent reference, it should also be visible in the class diagram. ##Proposed Resolution: Fixed Beta 1, August 2009 (pdf version) Make the following change in the specification: Update figure "The Participant Class Diagram" (figure 8.40 in Beta 1, draft 1) to include class "Process" and association(s) between the Participant and Process classes. This is important as table "Participant attributes and model associations" (table 8.53, in Beta 1, draft 1) defines attribute processRef, but it is not shown in figure 8.40. No MM and XSD updates are necessary. |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:34 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 26/Mar/10 09:20 AM ] |
|
------------------- Proposal ------------ 2010-03-26 -------------------------------------------------
##Proposed Resolution: Fixed Make the following change in the specification: Update figure "The Participant Class Diagram" (figure 8.40 in Beta 1, draft 1) to include class "Process" and association(s) between the Participant and Process classes. This is important as table "Participant attributes and model associations" (table 8.53, in Beta 1, draft 1) defines attribute processRef, but it is not shown in figure 8.40. No MM and XSD updates are necessary. |
| Comment by Ivana Trickovic [ 26/Mar/10 09:20 AM ] |
| New Proposed Resolution |
[BPMNFTF-491] [OMG 14860] The Message element structureRef association should be renamed to itemRef
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White, wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: 8 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 86 Title: The Message element structureRef association should be renamed to itemRef Nature: Revision Severity: Minor The Message element has an association named "structureRef," which points to the ItemDefinition element. It should be renamed "itemRef." -----Proposal---------------- 02/16/2010 ------------------------- ##Proposed Resolution: Fixed (a) Replace Figure 8.34 (pg 116) Update the UML metamodel, renaming Message.structureRef to itemRef (b) Update Table 8.50 (pg 116) Rename structureRef to itemRef (c) Update Table 8.71 (pg 134) - XSD snippet Rename structureRef to itemRef |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:06 AM ] |
|
-----Proposal---------------- 02/16/2010 -------------------------
##Proposed Resolution: Fixed (a) Replace Figure 8.34 (pg 116) Update the UML metamodel, renaming Message.structureRef to itemRef (b) Update Table 8.50 (pg 116) Rename structureRef to itemRef (c) Update Table 8.71 (pg 134) - XSD snippet Rename structureRef to itemRef |
| Comment by Stephen White [ 17/Feb/10 06:15 PM ] |
| New Proposed Resolution |
[BPMNFTF-490] [OMG 14859] Property name mismatch between Spec and Schema for Item Definition
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White, wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: 8 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 82 Title: Property name mismatch between Spec and Schema for Item Definition Nature: Revision Severity: Minor The MM and spec shows ItemDefinition with a property named "structure." The schema names this property "structureRef." These two should be synchronized. Mostly likely, the spec and MM should be changed. -----Proposal---------------- 02/16/2010 ------------------------- ##Proposed Resolution: Fixed (a) Update the UML metamodel, renaming ItemDefinition.structure to structureRef Replace Figures 8.20, 8.22, 8.27, 8.34, 10.47, 10.48, 10.52, 10.53, 10.56, 10.58, 10.61, 10.70, 10.75, 10.77, 10.84, 10.89 (b) Update Table 8.49 (pg 113) Rename structure to structureRef |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:20 AM ] |
|
-----Proposal---------------- 02/16/2010 -------------------------
##Proposed Resolution: Fixed (a) Update the UML metamodel, renaming ItemDefinition.structure to structureRef Replace Figures 8.20, 8.22, 8.27, 8.34, 10.47, 10.48, 10.52, 10.53, 10.56, 10.58, 10.61, 10.70, 10.75, 10.77, 10.84, 10.89 (b) Update Table 8.49 (pg 113) Rename structure to structureRef |
| Comment by Stephen White [ 17/Feb/10 06:13 PM ] |
| New Proposed Resolution |
[BPMNFTF-489] [OMG 14858] "isInterrupting" attribute of Start Events
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.4.2 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 251,294 Title: "isInterrupting" attribute of Start Events Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The "isInterrupting" attribute is introduced in the start events to deal with the possible non interrupting nature of start events in the context of Event Sub-processes. It is to be ignored for other Start Events. A few issues: In Table 10-112 on page 294. The schema snippet is missing the "isInterrupting" attribute. In Table 10-80 on page 251 the isInterrupting attribute has no default value whereas the semantic.xsd file does set it by default to "false" Should we remove the default value from the schema or should we set the "isInterrupting" attribute to "true" by default so that if that attribute is pushed in the context of a normal start event the proper depiction will be rendered. (Eventhough it should have been ignored..) ##Proposed Resolution: Fixed (a) Table 10.80, first row, first column: add " = true" (b) Table 10.122, replace "<xsd:extension base="tCatchEvent"/>" with the following: "<xsd:extension base="tCatchEvent"> <xsd:attribute name="isInterrupting" type="xsd:boolean" default="true"/> </xsd:extension>" (c) change the default of the isInterrupting attribute to true in the schema and metamodel |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 08:01 AM ] |
|
As per March F2F Meeting:
- As the attribute is valid only for event sub-processes make it optional. - Add that it MUST be used for event sub-processes and MUST not be used for other process types. |
| Comment by Stephen White [ 18/Mar/10 08:55 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-488] [OMG 14854] Add Brief Description for Error and Escalation Event
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 10 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 241 Title: Add Brief Description for Error and Escalation Event Definitions Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: The other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description. ##Proposed Resolution: Defer This issue is related to section 10.4.5 (Event Definitions) Conditional, Error, and Escalation Events are properly described in other sections, so there is no lack of information. Consequently, this issue will be deferred to the RTF to properly unify/correlate the descriptions in the different sections. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 01:28 PM ] |
| Actually only a few event definitions have a description. I think we should add the brief description in all. |
| Comment by Ivana Trickovic [ 10/Mar/10 04:39 AM ] |
|
As per March F2F Meeting:
- This is an editorial issue. Needed text is already available in the document (in different sections). - Agreed to lower the priority to minor. |
[BPMNFTF-487] [OMG 14848] Allow Overlapping Matrix Construction of Lanes in a Diagram
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Denis Gagne |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 13 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 361 Title: Allow Overlapping Matrix Construction of Lanes in a Diagram Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The spec has always described the ability to create matrix types of Lanes in diagrams. The current DI MM does not allow this. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:34 PM ] |
|
##Proposed Resolution: Close, No Change
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-486] [OMG 14778] Annex D Glossary [Specification]: Update Glossary
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Annex_C -- Issue 486.doc
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-279 ##Original Info: (Severity: Significant - Nature: Enhancement) The Glossary has been taken from V1.1 and needs to be updated. ##Proposed Resolution: Fixed Changes to Annex C: Glossary (a) Reformat the descriptions of the definitions so that the definition is not repeated in the description. For example, change the beginning of the Activity definition from: "An activity is a generic term for work that a company or organization performs via business processes" To: "Work that a company or organization performs using business processes." (b) Remove WfMC definitions from Glossary (some of these definitions will be merged with BPMN terms (see below) (c) Remove Workflow Pattern definitions from Glossary (d) "Abstract Process" Definition: change definition to "A process that represents the interactions between a private business process and another process or participant." (e) "AND-Join" Definition: Delete this topic and merge the definition with "Join" (see below) (f) "Join" Definition: Replace definition with the following: "A point in the Process where two or more parallel Sequence Flow paths are combined into one Sequence Flow path. BPMN uses a Parallel Gateway to perform a Join. Also known as "AND-Join."" (g) "AND-Split" Definition: Delete this topic and merge the definition with "Fork" (h) "Fork" Definition: Replace definition with the following: "A point in the Process where one Sequence Flow path is split into two or more paths that are run in parallel within the Process, allowing multiple activities to run simultaneously rather than sequentially. BPMN uses multiple outgoing Sequence Flows from Activities or Events or a Parallel Gateway to perform a Fork. Also known as "AND-Split." (i) "Artifact" Definition: remove last two sentences. (j) "Association" Definition: replace definition with the following: "A connecting object that is used to link information and Artifacts with Flow Objects. An association is represented as a dotted graphical line with an arrowhead to represent the direction of flow." (k) "Business Analyst" Definition: replace the definition with "A specialist who analyzes business needs and problems, consults with users and stakeholders to identify opportunities for improving business return through information technology, and defines, manages, and monitors the requirements into business processes." (l) "Business Process" definition: replace definition with the following: "A defined set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources." (m) Remove the "Business Process Definition" item. (n) "Business Process Management" definition: replace definition with the following: "management (for example, process analysis, definition, processing, monitoring and administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between departments and applications." (o) "Choreography" definition: replace definition with the following: "An ordered sequence of message exchanges between two or more Participants. In a Choreography there is no central controller, responsible entity, or observer of the Process." (p) "Collaboration" definition: replace definition with the following: "of message exchanges between two or more Participants." (q) "Compensation Flow" definition: replace definition with the following: "Flow that defines the set of activities that are performed while the transaction is being rolled back to compensate for activities that were performed during the Normal Flow of the Process. A Compensation Flow can also be called from a Compensate End or Intermediate Event." (r) Remove the "Controlled Flow" item. (s) "Decision" definition: replace definition with the following: "A gateway within a business process where the Sequence Flow can take one of several alternative paths. Also known as "Or-Split."" (t) "End Event" definition: replace first sentence with: "An event that indicates where a path in the process will end." (u) "Event Context" definition: replace definition with the following: "An activity or group of activities in an expanded Subprocess that can be interrupted by an exception (such as an Error Intermediate Event)." (v) "Exception" definition: replace definition with the following: "An event that occurs during the performance of the Process that causes a diversion from the Normal Flow of the Process. Exceptions can be generated by Intermediate Events, such as time, error, or message." (w) "Exception Flow" definition: replace definition with the following: "A Sequence Flow path that originates from an Intermediate Event attached to the boundary of an activity. The Process does not traverse this path unless the Activity is interrupted by the triggering of a boundary Intermediate Event (an Exception - see above)." (x) "Expanded Sub-Process" definition: replace definition with the following: "A Sub-Process that exposes its flow detail within the context of its Parent Process. An Expanded Sub-Process is displayed as a rounded rectangle that is enlarged to display the Flow Objects within." (y) "Flow" definition: replace definition with the following: "A directional connector between elements in a Process, Collaboration, or Choreography. A Sequence Flows represents the sequence of Flow Objects in a Process or Choreography. A Message Flow represents the transmission of a Message between Collaboration Participants.The term Flow is often used to represent the overall progression of how a Process or Process segment would be performed." (z) "Flow Object" definition: replace definition with the following: "A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways." (a2) "Intermediate Event" definition: replace the definition with: "An event that occurs after a Process has been started. An Intermediate Event affects the flow of the process by showing where messages and delays are expected, distributing the Normal Flow through exception handling, or showing the extra flow required for compensation. However, an Intermediate Event does not start or directly terminate a process. An Intermediate Event is displayed as a circle, drawn with a thin double line." (b2) "Lane" definition: replace the definition with: "A partition that is used to organize and categorize activities within a Pool. A Lane extends the entire length of the Pool either vertically or horizontally. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), or an internal department (e.g., shipping, finance)," (c2) "Merge" definition: replace the definition with: "A point in the Process where two or more alternative Sequence Flow paths are combined into one Sequence Flow path. No synchronization is required because no parallel activity runs at the join point. BPMN uses multiple incoming Sequence Flows for an Activity or an Exclusive Gateway to perform a Merge. Also know as "OR-Join."" (d2) Remove "OR-Join" and merge it's definition with the "Merge" item. (e2) "Message" definition: replace the definition with: "An Object that depicts the contents of a communication between two Participants. A message is transmitted through a Message Flow and has an identity that can be used for alternative branching of a Process through the Event-Based Exclusive Gateway." (f2) "Message Flow" definition: replace the definition with: "A Connecting Object that shows the flow of messages between two Participants. A Message Flow is represented by a dashed lined." (g2) "Normal Flow" definition: replace the definition with: "A flow that originates from a Start Event and continues through activities on alternative and parallel paths until reaching an End Event." (h2) Remove OR-Split and merge definition with Decision (i2) Remove Parallel Split item (j2) "Participant" definition: replace last sentence in definition with: "In a Collaboration, Participants are informally known as "Pools." (k2) "Pool" definition: replace the definition with: "A Pool represents a Participant in a Collaboration. Graphically, a Pool is a container for partitioning a Process from other Pools/Participants. A Pool is not required to contain a Process, i.e., it can be a "black box." " (l2) "Private Business Process" definition: replace the definition with: "A process that is internal to a specific organization, generally called a workflow or BPM process." (m2) "Process" definition: replace the definition with: "A sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN, a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhere to a finite execution semantics." (n2) "Result" definition: replace the definition with: "The consequence of reaching an End Event. Types of Results include Message, Error, Compensation, Signal, Link, and Multiple." (o2) "Start Event" definition: replace the definition with: "An Event that indicates where a particular Process starts. The Start Event starts the flow of the Process and does not have any incoming Sequence Flow, but can have a Trigger. The Start Event is displayed as a circle, drawn with a single thin line." (p2) "Sequence Flow" definition: replace the definition with: "A connecting object that shows the order in which activities are performed in a Process and is represented with a solid graphical line. Each Flow has only one source and only one target. A Sequence Flow can cross the boundaries between Lanes of a Pool but cannot cross the boundaries of a Pool." (r2) "Task" definition: Replace third sentence of the definition with the following: "Generally, an end-user, an application, or both will perform the Task." (s2) "Token" definition: replace the definition with: "A theoretical concept that is used as an aid to define the behavior of a Process that is being performed. The behavior of Process elements can be defined by describing how they interact with a token as it "traverses" the structure of the Process. For example, a token will pass through an Exclusive Gateway, but continue down only one of the Gateway's outgoing Sequence Flow." (t2) "Transaction" definition: in first sentence, replace "A Transaction is" with "A Sub-Process that represents" (u2) "Trigger" definition: replace first sentence with "A mechanism that detects an occurrence and can cause additional processing in response, such as the start of a business Process." (v2) "Uncontrolled Flow" definition: replace the definition with: "Flow that proceeds without dependencies or conditional expressions. Typically, an Uncontrolled Flow is a Sequence Flow between two Activities that do not have a conditional indicator (mini-diamond) or an intervening Gateway." |
| Comments |
| Comment by Stephen White [ 13/Sep/09 11:15 PM ] |
| The version number was removed from the summary so that it will apply to the Beta 1 spec |
| Comment by Pete Rivett [ 15/Apr/10 11:13 AM ] |
| We should not perpetuate an out of date Glossary which will cause confusion all round - if it really cannot be updated then it should be removed. |
| Comment by Mariano Benitez (Oracle) [ 15/Apr/10 11:56 AM ] |
|
I agree it is another possibility, but I am not sure which one would have the worst impact... no glossary or an incorrect one...
We can discuss on Monday Apr 19th if more people agree to remove, we can change the proposal, or leave 2 proposals for vote. |
[BPMNFTF-485] [OMG 14775] Beta 1 Spec: Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-298 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 1 of 12 issues submitted by Bruce Silver: Define explicit separation of "modeling" vs "implementation" attributes. The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set. Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties. Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression. Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc. Those are for implementation; in modeling it's the diagram that counts, i.e. the label. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 05/Feb/10 12:14 PM ] |
|
Withdrawn Resolution: Defer or Close with no change
I believe we have done some improvements in this field, with executable and non executable, isImmediate, etc. Maybe we chose a different path than what this issue is expecting. Nevertheless, there is already work in this path, so I would not do any new thing in this FTF. So it is a defer or a close with no change. Regards, |
| Comment by Stephen White [ 18/Mar/10 08:56 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:00 AM ] |
| Update the proposed issue resolution to say that this is not an implementation issue so the FTF agreed to defer this issue. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:14 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-484] [OMG 14803] Can a sub-process (embedded) have Lanes?
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Meera Srinivasan (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Meera Srinivasan, meera.srinivasan@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-59 ##Original Info: (Severity: Significant - Nature: Enhancement) Section 10.2.5, Page 152 (page 182 in PDF) Can a sub-process (embedded) have Lanes? My understanding is no. Can the specification clarify this clearly? ------------------ Proposal -------------- 2010-02-18 ------------------------------------ ##Proposed Resolution: Fixed Move the laneSets attribute from Process to FlowElementContainer: (a) Table 10.1, page 124 (154 pdf): remove 4th row from table (laneSets) (b) Table 8.46, page 78 (108 pdf): add the following row to the table: laneSets: LaneSet [0..*] || This attribute defines the list of LaneSets used in the Flow Element Container (e.g., Process, Sub-Process). LaneSets are not used for Choreographies or Sub-Choreographies." (c) Section 9.2.1, page 117 (147 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-Process and will extend the entire length of the Process level, either vertically or horizontally." (d) Section 10.7, page 282 (312 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-Process and will extend the entire length of the Process level, either vertically (see figure XX) or horizontally (see figure XX)." (e) Section 10.7, page 282 (312 pdf): remove second sentence in section. (f) Figure 10.122, page 285 (315 pdf): replace figure to show the change in the laneSet attribute (g) Table 10.43, page 181 (211 pdf): add the "laneSet" element to the Sub-Process schema snippet. Also add this element to the BPMN XSD. ----------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 09/Sep/08 06:56 PM ] |
| The answer is no. We will make this clear in the spec. |
| Comment by Stephen White [ 11/Mar/09 01:33 PM ] |
| The answer to this is now less clear. Lanes are now contained in a Process, rather than a Pool as was in BPMN 1.X. Thus, it might be possible to have lanes in sub-processes. We are investigating the semantic and visual model consequences. |
| Comment by Mariano Benitez (Oracle) [ 10/Jun/09 01:45 PM ] |
|
if you are calling another process (via call activity), then the other process can have lanes, and they should be visually represented.
Right now (v0.9.14), a sub-process can only contain flow elements and artifacts, not lanesets. I think we should allow lanesets in subprocess. |
| Comment by Stephen White [ 11/Sep/09 01:23 PM ] |
| The section and page numbers were updated to match the Beta 1 Spec |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 07:05 PM ] |
| Both called subprocesses and embedded subprocesses should have lanes. Would significantly reduce the value of lanes if they didn't. |
| Comment by Stephen White [ 17/Feb/10 05:16 PM ] |
|
-------------- Discussed during Conference Call on 2010-02-17 ---------------------
Sub-Processes do not have LaneSets. To provide them with the functionality, the LaneSets attribute will be moved to the FlowElementContainer element ----------------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 18/Feb/10 01:35 PM ] |
|
------------------ Proposal -------------- 2010-02-18 ------------------------------------
Move the laneSets attribute from Process to FlowElementContainer: (a) Table 10.1, page 124 (154 pdf): remove 4th row from table (laneSets) (b) Table 8.46, page 78 (108 pdf): add the following row to the table: laneSets: LaneSet [0..*] || This attribute defines the list of LaneSets used in the Flow Element Container (e.g., Process, Sub-Process). LaneSets are not used for Choreographies or Sub-Choreographies." (c) Section 9.2.1, page 117 (147 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-Process and will extend the entire length of the Process level, either vertically or horizontally." (d) Section 10.7, page 282 (312 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-Process and will extend the entire length of the Process level, either vertically (see figure XX) or horizontally (see figure XX)." (e) Section 10.7, page 282 (312 pdf): remove second sentence in section. (f) Figure 10.122, page 285 (315 pdf): replace figure to show the change in the laneSet attribute (g) Table 10.43, page 181 (211 pdf): add the "laneSet" element to the Sub-Process schema snippet. Also add this element to the BPMN XSD. ----------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 18/Feb/10 01:35 PM ] |
| New Proposed Resolution |
[BPMNFTF-483] [OMG 14785] Generalize message flow
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Model Driven (Cory Casanave, corycasanave@modeldriven.org)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-239 ##Original Info: (Severity: Significant - Nature: Enhancement) The specification contains this constraint: Note that Message Flow cannot connect to objects that are within the same Pool. There is no reason to have this constraint and it artificially constrains the model. Many process modeling paradigms (including UML) provide for flows between activities within a process. It is common to refactor processes in which case the interactions don't change - but they may move to another pool. From a business perspective we may well have a message between activities, even if we have not delineated all the participants. The constraint should be removed. This could be acheaved by a more general treatment of interactions. ##Proposed Resolution: Closed, No Change This proposal would change basic design principles in BPMN. Hence, we do not want to fix this. |
| Comments |
| Comment by Conrad Bock (NIST) [ 15/Oct/08 09:48 AM ] |
| Related to http://www.osoa.org/jira/browse/BPMN-229 (Mariano is working on it). |
| Comment by Bruce Silver [ 05/Dec/08 06:52 PM ] |
| This would fundamentally change one of BPMN's core concepts, message, which currently is any type of signal exchanged between processes (pools). |
| Comment by Mariano Benitez (Oracle) [ 10/Jun/09 01:36 PM ] |
|
One way or another, we need a resolution for this problem with pools and processes.
I personally think we should allow message flows between activities of the same process, or even between processes, but without a collaboration diagram. Collaboration diagrams seems like an overkill for me in the case of simple inter-process synchronization (private processes that add up to the big business process). |
[BPMNFTF-482] [OMG 14793] Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process?
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-158 ##Original Info: (Severity: Significant - Nature: Enhancement) The collapsed Sub-Process has a "plus" sign marker. Should the expanded Sub-Process have a "minus" sign marker. Many tools already do this. --------------------- New Proposed Resolution --------- 2010-02-11 ---------------------------- ##Proposed Resolution: Close: No Change Close; no change The FTF decided that the issue report does not identify a problem with this specification ------------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 05/Mar/09 07:41 PM ] |
| Given the current schedule, this issue will not be addressed in the RFP process. This issue can be reopened by the BPMN 2.0 FTF. |
| Comment by Stephen White [ 12/Sep/09 01:35 PM ] |
| The Section and Figure numbers were updated to match the Beta 1 spec |
| Comment by Stephen White [ 11/Feb/10 01:27 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
Standardize minus sign We would have to change a lot of examples Add some text definitions Action: Close, no change |
| Comment by Stephen White [ 11/Feb/10 01:30 PM ] |
|
--------------------- New Proposed Resolution --------- 2010-02-11 ----------------------------
Close; no change The FTF decided that the issue report does not identify a problem with this specification ------------------------------------------------------------------------------------------------------------------- |
[BPMNFTF-481] [OMG 14774] Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-299 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 2 of 12 issues submitted by Bruce Silver Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity. At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity. Also remove the language that multiple pools in a BPD are about B2B. This is rarely the case. Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B. |
| Comments |
| Comment by Bruce Silver [ 05/Dec/08 05:51 PM ] |
| I suspect I will not carry the day on this one. I see there was language to this effect in early November and then deleted later. Can we at least say that a pool may contain at most one process? |
| Comment by Stephen White [ 15/Sep/09 02:28 PM ] |
| The section number was removed from the Summary to allow this to apply to the Beta 1 spec |
| Comment by Stephen White [ 19/Mar/10 06:10 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:29 AM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:24 AM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-480] [OMG 14788] Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-228 ##Original Info: (Severity: Significant - Nature: Enhancement) We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 08/Oct/08 03:57 PM ] |
|
We also dropped the concept of "streaming" data, so this should also be included in this section.
Assignments elements are also removed, converted to DataAssociations. |
| Comment by Stephen White [ 12/Sep/09 01:47 PM ] |
| Spec Draft version removed to prepare for BPMN 2.0 FTF |
| Comment by Mariano Benitez (Oracle) [ 22/Mar/10 07:12 AM ] |
|
##Proposed Resolution: Defer
This section is not normative, so like the examples, they can be completed by an RTF. And the FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
[BPMNFTF-479] [OMG 14784] Define "Pool"
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 1 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: Model Driven (Cory Casanave, corycasanave@modeldriven.org)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-241 ##Original Info: (Severity: Significant - Nature: Enhancement) The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a process. It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" does not seem to have any semantic relevance to process. Examples: • While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants). • A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. • Nor can Sequence Flow cross a Pool boundary. • For message exchanges between pools, Conversations are used to group several Message Flow • A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool. The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics. -----------Proposal----------------Apr 5, 2010--------------------------- ##Proposed Resolution: Defer > The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. > It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" > does not seem to have any semantic relevance to process. The second paragraph of the Collaborations section explains that Pools are a notation for Participants. As a notation, they don't have a semantics by themselves, this is specified for Participant. Sometimes the term Pool is used interchangably with Participant, but this is in the informal way of referring to elements by their notation. One option might be to replace all uses of Pool with Participant. The relationship between participants and processes are the subject of issue BPMNFTF-406 [OMG 14709]. > Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a > process. This is the subject of issue BPMNFTF-481 [OMG 14774]. > While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants). > Nor can Sequence Flow cross a Pool boundary. > A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a > graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. This is is currently a design decision taken in BPMN, that processes and interactions are separate. Can discuss more in RTF. > For message exchanges between pools, Conversations are used to group several Message Flow This follows from pools being a notation for participants in interactions. > A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) > responsible for the execution of the Process enclosed in a Pool. This is done with PartnerEntities or PartnerRoles linked to Participants. Participants can share the same PartnerEntity or PartnerRole. The issue is deferred for more discussion in RTF, in conjunction with issues BPMNFTF-406 [OMG 14709] and BPMNFTF-481 [OMG 14774] |
| Comments |
| Comment by Bruce Silver [ 05/Dec/08 06:49 PM ] |
| I agree w/Cory. Pool has fundamental semantics, unlike Lane which is purely notational. Sequence flow from start to end constrained within a pool. Message flow must connect two pools. A pool can contain at most one process (not counting subprocess activities within that process). Etc. For some reason BPMN refuses to say a pool is a container for a process. Instead it says a pool is a visual expression of a "participant" - role or entity - even though behind-the-firewall collaborations between pools representing the exact same role or entity are not uncommon. They are separate pools not because they represent different participants but because of their independent lifetime and cardinality. |
| Comment by Mariano Benitez (Oracle) [ 29/Dec/08 01:29 PM ] |
|
Also in the XSD schema the conversation element has a unbounded reference to a "pool" element. The MM do not mention Pool, but it is defined in the XSD.
|
| Comment by Bruce Silver [ 27/Jan/09 06:28 PM ] |
| The MM element for pool should be process. A BPD (sorry, "collaboration diagram") with two collaborating processes representing the exact same role or business entity contains two pools interacting via message flows. Pool is a visual element, process is the MM element. The pool always exists but sometimes is invisible. So it is a Zen visual element. |
| Comment by Stephen White [ 27/Jan/09 06:47 PM ] |
|
I don' think that a Process is the same as a Pool. For one, a Process can appear in more than one Pool. For example, WalMart could play two Roles in a Collaboration, occupying two Pools. Those two Pools could have different Processes, but those two Pools could actually use the same Process (if the Modeler chooses).
The Pool, which we have been equating to Participant lately, may or may not reference (contain) a Process. |
| Comment by Mariano Benitez (Oracle) [ 30/Jan/09 07:53 AM ] |
|
Steve,
In your example: Could you describe how the MM would look like in both cases (same process in both pools and different processes)? Probably I don't fully understand Collaboration, but how does a sequence flow whose target is a pool woud relate to the real process? |
| Comment by Bruce Silver [ 30/Jan/09 12:04 PM ] |
| Steve's example is enlightening, because it shows the problem is lack of clarity on what is a "process." To me, his example describes two processes, not one. A BPMN process is an orchestration, a continuous flow of control from start to end events via sequence flow. A "business process" may indeed have more than one BPMN process, perhaps even performed by the same participant (WalMart), acting in same role (or different roles) in multiple pools. The reason they are separate processes/pools is that 1) they have independent lifetimes; 2) they may have independent cardinality. In BPEL no one has trouble with this distinction. A business process is very often composed of multiple BPEL processes. Why is this not a single BPEL process? For many of the same reasons as in BPMN. The BPMN spec explicitly says a process is not a "thing" but a collection of things. I don't think this is consistent with BPMN 2.0 MM. If we can agree that a BPMN process is a thing, then I think the pool question will be simpler to resolve. |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 09:57 AM ] |
| proposalScheduledForBallot10 |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 09:30 AM ] |
| New Proposed Resolution: Close, No Change |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 09:30 AM ] |
|
-----------Proposal----------------03/26/2010---------------------------
##Proposed Resolution: Close, No Change The second paragraph of the Collaborations section explains that Pools are a notation for Participants. As a notation, they don't have a semantics by themselves, this is specified for Participant. |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:26 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Defer > The term "pool" is used extensively in the specification yet the > definition seems inconsistent and not tied to the meta model. > It seems to be a graphical element but shows up on ends of > associations and in definitions of the semantics. The term "pool" > does not seem to have any semantic relevance to process. The second paragraph of the Collaborations section explains that Pools are a notation for Participants. As a notation, they don't have a semantics by themselves, this is specified for Participant. Sometimes the term Pool is used interchangably with Participant, but this is in the informal way of referring to elements by their notation. One option might be to replace all uses of Pool with Participant. The relationship between participants and processes are the subject of issue BPMNFTF-406 [OMG 14709]. > Sometimes a pool seems to be the role of a participant in a process > context. In other cases it seems to be the essential container of a > process. This is the subject of issue BPMN-FTF 481 [OMG 14774]. > While a normal Process exists within a Pool, a Choreography exists > between Pools (or Participants). > Nor can Sequence Flow cross a Pool boundary. > A Pool is the graphical representation of a Participant in a > Collaboration (see page 235). It is also acts as a "swimlane" and a > graphical container for partitioning a set of Activities from other > Pools, usually in the context of B2B situations. This is is currently a design decision taken in BPMN, that processes and interactions are separate. Can discuss more in RTF. > For message exchanges between pools, Conversations are used to > group several Message Flow This follows from pools being a notation for participants in interactions. > A Participant is a specific business entity (e.g., a company) or a > more general business role (e.g., a buyer, seller, or manufacturer) > responsible for the execution of the Process enclosed in a Pool. This is done with PartnerEntities or PartnerRoles linked to Participants. Participants can share the same PartnerEntity or PartnerRole. The issue is deferred for more discussion in RTF, in conjunction with issues BPMNFTF-406 [OMG 14709] and BPMN-FTF 481 [OMG 14774]. |
[BPMNFTF-478] [OMG 14780] Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-268 ##Original Info: (Severity: Significant - Nature: Revision) Revision of Spec: Beta 1 Section(s) of Spec: 10.2.3, subsection "Types of Task", subsubsection "Business Rule Task" Raised by: Matthias Kloppmann Sub-Team responsible: Type: Technical Description of issue:The description of the business rule task just describes its shape, but doesn't state its purpose. Proposal: Add a single sentence such as "A business rule task calls a business rule and returns its result into the process." -------- New Proposed Resolution ---------- 2010-01-20 -------------------------------- ##Proposed Resolution: Close; no change This issue has been fixed before the Beta. There is a description for the BR Task in section 10.2.3 (page 141/pdf 171) and in execution semantics, section 14.2.3 (page 393/pdf 424) ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 14/Oct/08 10:27 AM ] |
| BPMN-143 assumes the proposed resolution for BPMN-268. |
| Comment by Bruce Silver [ 05/Dec/08 06:21 PM ] |
|
I propose the following tweak as more informative and more consistent w/language of business rule people:
"A business rule task is a specific type of service task that calls a decision or ruleset on a business rule engine and returns its result to the process." |
| Comment by Mariano Benitez (Oracle) [ 16/Dec/09 03:44 PM ] |
|
New Proposed Resolution: Fixed
(see Bruce Silver's previous comment) |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 02:47 PM ] |
|
After reviewing the issue it appears to be fixed. So this issue is now obsolete.
The updated proposed resolution is to close it with no change. |
[BPMNFTF-477] [OMG 14790] Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-183 ##Original Info: (Severity: Significant - Nature: Revision) We have created some guards around the use of unavailable data in expressions of Data Associations. The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned. ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. A proper resolution would include guards on each usage of expressions, including sequence flows, but also on loop characteristics, conditional events, etc. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:59 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-476] [OMG 14795] Default execution semantics for an activity with multiple incoming branches needs to be clarified
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Vishal Saxena (Oracle) | Assigned To: | Hagen Volzer |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
1Open-NoClose.png
2Open-NoClose.png
3 Open-NoClose.png
3act-loop.png
CustomerCase-names changed.png
default-Exec-Semantics.jpg
loop.png
ParallelEventSub-Process.png
Proposal-BPMN-117-b1.doc
Proposal-BPMN-117-c.doc
Proposal-BPMN-117.doc
|
| Description |
|
##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-117 ##Original Info: (Severity: Significant - Nature: Revision) The current execution semantics apparently implies that the said activity with two incoming connections will be executed twice. Instead it should be a merge semantics that is the activity is executed once when token arrives on both branches. ------------------------ New Proposed Resolution ----------- 2010-02-03 ---------------------------- ##Proposed Resolution: Close; No Change The proposal in the issue description is in conflict with start events on the boundary of a sub-process as explained above and also conflicts compatibility with BPMN 1.1. Thus, we propose to close with no change. ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Hagen Volzer [ 11/Sep/08 08:32 AM ] |
| Changing the semantics here would probably result in a more intuitive description since with most languages, multiple incoming sequence flow means synchronization. On the other hand, this would clearly be a major change with respect to BPMN 1.1, violating one of our design principles. This issue needs to be discussed in the big round. |
| Comment by Hagen Volzer [ 15/Sep/08 06:07 PM ] |
| After discussion in the exec semantics subgroup, the proposal is to define multiple incoming sequence flow as a macro for an inclusive gateway. |
| Comment by Conrad Bock (NIST) [ 08/Oct/08 05:49 PM ] |
|
Add to http://www.osoa.org/jira/browse/BPMN-117
The description of controlled vs uncontrolled flow is very simple and intuititve, as described in the spec: Uncontrolled flow means that, for each Token arriving on any incoming path into the Activity, the Task will be enabled independently of the arrival of Tokens on other incoming flows. The presence of multiple incoming sequence flows behaves as an exclusive gateway. If the flows need to be $(Aco(Bntrolled$(B, (B then gateways should be explicitly included in the Process flow to fully eliminate semantic ambiguities. It is unclear that using inclusive merge instead will be as good. The experience Sylvain and I have with BPMN and UML suggests the current BPMN semantics is a value-add unique to BPMN. Also see comments on inclusive merge at http://www.osoa.org/jira/browse/BPMN-254. |
| Comment by Vishal Saxena (Oracle) [ 04/Nov/08 06:45 PM ] |
|
Hi Conrad
If we have the following flow (parallel gateway from A to B and C): --B---- A-- D --C----- Going by the current semantics, It might be clear to the user that D may be executed twice. However, if this is repeated e.g. (parallel gateway from A to B and C and also from W to X and Y) --B---- --X----- A-- D ----- P - --Q ---R ---S ---W-- --Z --C----- --Y----- It is completely un-intutive that all activities D onward may be repeated twice and all activities Z onward may be repeated 4 times. Therefore we had agreed in the side group meeting to clarify the semantics to "multiple incoming sequence flow means synchronization". |
| Comment by Vishal Saxena (Oracle) [ 04/Nov/08 07:00 PM ] |
| Another example with current default semantics |
| Comment by Vishal Saxena (Oracle) [ 04/Nov/08 07:02 PM ] |
|
In the attached example for clarification - Activity B may be executed twice but D will be executed 4 times and all such subsequent activities will be executed *2 times.
Hence we had proposed to clarify the default execution semantics as captured in Hagen's comment. |
| Comment by Sylvain Astier (Axway) [ 07/Dec/08 07:46 PM ] |
|
I believe the current semantic to be clear. I have never encountered any one who expressed some difficulties with this. I think it's really "business friendly" as businesss modelers from our mother company tend to like it this way.
On top of this I would like to point out that this semantic is actually inherited from Petri Nets, so if we want to modify it (that is if we found a real business case for it) we will need to be very careful not messing with our root structure.. |
| Comment by Stephen White [ 09/Dec/08 01:09 PM ] |
|
I agree with Sylvain and don't think we should change the semantics that were in BPMN 1.1 (and currently in the spec).
If we need better descriptions (including examples) of when and why Gateways are needed and what happens when they are not used, then we should do that. |
| Comment by Vishal Saxena (Oracle) [ 09/Dec/08 01:55 PM ] |
|
Me and Sylvain had a conversation at the OMG meeting in Santa Clara yesterday (Dec8). We sort of agreed that if an activity is supposed to be executed multiple times, then it should be a explicitly marked as a multi instance activity. This will :
- remove the ambiguity of activity B, X, Y , Z, C1 & C2 being executed twice while D being executed 4 times. - preserve the current ability of users to let some activities execute multiple times, if so desired. The proposal to define multiple incoming sequence flow as a macro for an inclusive gateway, was reached in the exec semantics subgroup. Steve - The flexibility to users of not having to always draw a closing gateway is a big plus of the BPMN spec. However, if we remove this subtle ambiguity we get a good mix of flexibility and clear execution semantics. |
| Comment by Mariano Benitez (Oracle) [ 10/Dec/08 08:40 AM ] |
|
I have some concerns about this change, I believe there are far more case where you expect uncontrolled flow and not a merge.
Consider the loop.png attachment, I would expect this to behave like an exclusive gateway, and I believe people would always tend to model a looping activity this way and not using the looping characteristics. This image is part of the spec, where it describes sequence flow looping. Another example would be how to treat multiple flows merging into the end event, the change in behaviour would mean that the end even will only be executed once when all the flows arrive? Our previous BPM tools (AquaLogic BPM) had the behaviour of treating multiple incoming sequence flows as uncontrolled flow, and we never had an issue with it. |
| Comment by Hagen Volzer [ 10/Dec/08 10:45 AM ] |
|
Mariano,
changing the default behavior into inclusive logic works should work fine with your loop example, i.e. the looping token does not wait for other tokens to synchronize with unless there are additional tokens upstream. This however should not happen in a clean model. (Otherwise there would be uncontrolled multiple instances of activities as in Vishals example). |
| Comment by Mariano Benitez (Oracle) [ 11/Dec/08 01:32 PM ] |
|
Hagen,
What I see in Vishal's example is that you are splitting and merging implicitly and that is not a typical case. I would model Vishal's case with parallel gateways enclosing A1 and A2, and also enclosing C1 and C2. That is a much cleaner model from a parallelism point of view. Shortcuts are good, and they should be used for the simple cases, the loop case is pretty basic and it should be handled with shortcuts. Vishal's example is more complex, so it is ok to handle it with explicit forking/merging gateways. Going back to your point that inclusive logic should work fine, what about a multi activity loop, with multiple tokens inside the flow? I would expect that the looping tokens do not merge, see 3act-loop.png. I would expect that if more than one token arrives at the first activity, it will not merge with other tokens. |
| Comment by Hagen Volzer [ 12/Dec/08 02:56 AM ] |
|
Mariano,
I don't see the difference between the 3-activity loop and the 1 activity loop, except that you should also put an exclusive gateway at the branching point (otherwise you get unbounded many tokens at the loop exit). Taken that change into account, there is no difference. I don't see multiple tokens inside the loop. |
| Comment by Vishal Saxena (Oracle) [ 27/Apr/09 07:26 PM ] |
|
1. XOR is counter intuitive. Most flow charts treat this as IOR
2. Default XOR causes ambiguity among modelers, as they cannot be sure how many times an activity gets executed at runtime. 3. Execution semantics are being crystallized in BPMN 2.0 and therefore even though this is a change from BPMN 1.1 - there were no engines supporting it. 4. If we desire the flexibility of multiple incoming tokens causing multiple instances of activity, it can always be preceded by an XOR gateway. 5. In real life examples, modelers could have multiple opening (XOR , IOR and AND - and a combination thereof) and only one closing activity. |
| Comment by Vishal Saxena (Oracle) [ 27/Apr/09 08:21 PM ] |
|
One option would be to change the current text:
"The presence of multiple /incoming/ Sequence Flow behaves as an exclusive gateway. If the flow of /Tokens/ into the Task needs to be 'controlled', then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Task to fully eliminate semantic ambiguities. " to: "The presence of multiple /incoming/ Sequence Flow behaves as an inclusive gateway. If the flow of /Tokens/ into the Task needs to be 'uncontrolled', then Gateways (other than Inclusive) should be explicitly included in the Process flow prior to the Task to fully eliminate semantic ambiguities. In the case of multiple boundary start events, alternative by nature, the sequence flow behaves as exclusive gateway. |
| Comment by Stephen White [ 27/Apr/09 10:33 PM ] |
|
>1. XOR is counter intuitive. Most flow charts treat this as IOR
Actually, I've only seen XOR or AND for multiple merging SF for an Activity. I've never seen IOR behavior for this. I suppose it could be used in some tools, but I don't think it is the most prevalent. Furthermore, I don't think that IOR is all that intutive of a concept. It is hard to explain properly and was the hardest one of the GWs for which to define the execution semantics. Hagen, I and others spent a long time coming up with the proper mechanisms to define IOR merging. >2. Default XOR causes ambiguity among modelers, as they cannot be sure how many times an activity gets executed at runtime. I don't think there is any ambiguity if they understand the behavior. XOR is easy to explain. They would understand how many times the activity gets executed if they know the behavior. And they would probably put a Gateway where necessary. The only ambiguity would be if they expect one behavior and get another. But alternative expectations could come in different flavors (e.g., IOR or AND). Proper training, which is necessary for any tool or notation, will eliminate the ambiguity. >3. Execution semantics are being crystallized in BPMN 2.0 and therefore even though this is a change from BPMN 1.1 - there were no engines supporting it. We don't know this for sure. There are over 50 tools supporting 1.X. I would expect some of them support the execution (or simulation) of the current behavior. |
| Comment by Vishal Saxena (Oracle) [ 29/Apr/09 03:26 PM ] |
|
Putting the onus on Business Analyst, to choose which GW type to use before multiple incoming sequences will be hard. As illustrated in the examples.
In the examples 1-3 above, it is not certain how many times E will execute. In 1 & 2 it will execute twice. In 3 it will execute either once or twice depending on the XOR gateway. The problem is exacerbated by a multitude when you have use cases like the one called customer use case (uploading now). I find the work on IOR GW very important and interesting. It has been very cleanly articulated using the term upstream. It would be great if we can leverage the good work to make the life of business modelers easier. In fact the proposal is also facilitating the multiple instances use case but only hen the user explicitly desires it (and therefore adds exclusive gateway). |
| Comment by Vishal Saxena (Oracle) [ 29/Apr/09 03:47 PM ] |
| A real life scenario built and executed using BPMN 1.1 |
| Comment by Stephen White [ 29/Apr/09 09:31 PM ] |
|
This real life scenario could also be seen as support for leaving the semantics as is.
The Process is already complex. Adding a few Gateways is not going to add to the complexity in a significant way nor will be an extreme burden for the users to add them. Actually, using the extra GWs would clarify the modeler's thinking about the behavior and the structure of the model, as well as the reader's understanding of the model. |
| Comment by Vishal Saxena (Oracle) [ 04/May/09 02:48 AM ] |
|
Seems like a common issue encountered by multiple engines:
http://www.vosibilities.com/soa/bpmn-bpel-both-whats-right-for-a-process-execution-standard/2008/12/08/ |
| Comment by Hagen Volzer [ 04/May/09 04:45 AM ] |
|
Changing the semantics to IOR is IMO in conflict with multiple boundary start events of subprocesses. The issue is:
- Have a look at the picture attached to http://www.osoa.org/jira/browse/BPMN-145 - The semantics is: (boundary) start events are alternative (XOR logic) - Now: If you collapse the subprocess, the boundary start events disappear and the incoming SF to the start events become incoming SF to the subprocess. This is line with the XOR semantics of multiple incoming SF of activities. - Assume both "Create water order" and "Create Supply order" are executed in parallel. If we had IOR semantics here, the semantics of the collapsed view would synchronize the tokens coming from these two tasks, whereas, in the expanded view, two instances of the subprocess need to be generated. When we discussed the issue at the F2F in Redwood Shores, we were not aware of boundary start events. |
| Comment by Hagen Volzer [ 04/May/09 05:11 AM ] |
|
My personal, subjective summary of the discussion so far:
pro IOR, con XOR - allows the modeler to omit gateways more often - establishes symmetry between in-logic and out-logic of an activity (sort of, AND might be cleaner here; BPMN is the only language I know where in-logic and out-logic differ.) con IOR, pro XOR - requires change with respect to BPMN 1.1 - in conflict with visualization of collapsed subprocesses with multiple boundary start events - requires more converging gateways, which makes converging flow logic more explicit |
| Comment by Vishal Saxena (Oracle) [ 07/May/09 01:15 AM ] |
| Attempts to address Hagen's concern on sub-process semantics. |
| Comment by Vishal Saxena (Oracle) [ 07/May/09 01:17 AM ] |
| ANother approach that distinguishes the behavior of the activity itself from that of the downstream activities. It keeps the BPMN 1.1 semantics but also addresses the downstream behavior which is the main concern. |
| Comment by Hagen Volzer [ 07/May/09 06:27 AM ] |
| I don't understand the proposal in Attachment Proposal-BPMN-117-c.doc. If you have XOR semantics on the front half, that means that you generate to instances of the "Announce Issues" activity. Each of these has to follow the lifecycle and hence each generates a token on the outgoing flow. There is no further opportunity to synchronize with IOR. |
| Comment by Hagen Volzer [ 07/May/09 06:58 AM ] |
| I object Vishals proposal in document "...-b1.doc". It basically says that you cannot tell the semantics if you look at the process with the collapsed subprocess. This would defeat one of the benefits of subprocesses, viz. that you can understand the process without looking into the subprocess. |
| Comment by Vishal Saxena (Oracle) [ 07/May/09 09:37 AM ] |
| Hagen, in the "Another example" I have provided an example where if we keep semantics as XOR, the sub process actually has IOR semantics because there is a multiple parallel event gateway. So the collapsed view is different from expanded view in any case. |
| Comment by Hagen Volzer [ 07/May/09 10:51 AM ] |
| "Another example" is not a valid process. |
| Comment by Hagen Volzer [ 03/Feb/10 07:40 AM ] |
|
New Proposed Resolution: Close with no change
There are no new arguments regarding this issue. Vishal's proposal is in conflict with start events on the boundary of a sub-process as explained above and also conflicts compatibility with BPMN 1.1. The orchestration subgroup therefore proposes to close with no change. |
[BPMNFTF-475] [OMG 14789] Section 10.2.8 [Execution Semantics] Loops: Loop names misleading
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Ivana Trickovic |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: SAP (Rouven Day, rouven.day@sap.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-194 ##Original Info: (Severity: Significant - Nature: Revision) Type: editorial Description of issue: The names "Standard Loop" and "Multi Instance Loop" are misleading. Actually both allow for creation of a desired number of Activity instances, not just Multi Instance Loops as the spec text states it. So the multiple instance characteristics is true for all loops, also Standard Loops. Thus the naming of the loop types is very misleading. Proposal: Go for the well known names (http://en.wikipedia.org/wiki/Control_flow#Loops). Rename Standard Loop to Condition-controlled Loop (or Conditional Loop or Condition-based Loop). Also find a better name for Multi Instance Loop. I´ll try to post some name proposals soon. |
| Comments |
| Comment by Stephen White [ 20/Mar/09 07:15 PM ] |
| The results of Issue 193 will also resolve this issue. |
| Comment by Stephen White [ 12/Sep/09 01:45 PM ] |
| The section number was updated to match the Beta 1 spec. |
| Comment by Ivana Trickovic [ 23/Mar/10 03:26 AM ] |
| proposalScheduledForBallot10 |
| Comment by Stephen White [ 24/Mar/10 03:40 PM ] |
|
----------- Conference Call on 2010-03-24 ---------------------
The Process Orchestration Sub-Group recommends that the issue be Closed; No Change. |
| Comment by Ivana Trickovic [ 12/Apr/10 07:46 AM ] |
|
##Proposed Resolution: Close; No Change
This is not an implementation issue so the proposal is to close the issue with no changes to the specification. |
[BPMNFTF-474] [OMG 14794] More description for "Process as a callable element"
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-118 ##Original Info: (Severity: Minor - Nature: Revision) On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction. |
| Comments |
| Comment by Stephen White [ 11/Sep/09 05:12 PM ] |
| The page and section numbers were updated to match the Beta 1 spec |
| Comment by Stephen White [ 19/Mar/10 06:14 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:02 AM ] |
| Update the proposed issue resolution to say that this is not an implementation issue so the FTF agreed to defer this issue. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:16 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-473] [OMG 14779] Tasks vs Global Tasks
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-271 ##Original Info: (Severity: Critical - Nature: Revision) The various kinds of tasks could also be global tasks. Section 10.2.7. Global Task says: There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. This is true for both Global Tasks and standard Tasks, where the list of task types is the same for both. For the sake of efficiency in this specification, the list task types is presented once on page 167. "Globalness" should be an attribute of Task, so the taxonomy of tasks does not need to be repeated. -----Proposal---------------- F2F 03/09/2010 ------------------------- ##Proposed Resolution: Closed, Out of Scope We do not consider making all tasks global something necessary. Besides simplicity and simetry, there is no added value to business users, since the refactoring would be done by tooling anyway, so they would not see a difference if the metamodel changes in one way or the other. We consider this issue to be part of this FTF, maybe a new RFP can handle it. |
| Comments |
| Comment by Rouven Day (SAP) [ 16/Oct/08 08:52 AM ] |
|
Hi Conrad, I see several problems with your proposals of defining globalness as an atribute of Task.
1) There is a clear distinction between embedded and referenced elements in BPMN (see embedded and referenced Sub-Processes). Same can apply to Tasks. Tasks can be embedded (normal Task). Then it is contained in a FlowElementContainer (e.g. Process) and by design not construced for reuse. 2) If you want to make something reusable you must be able to define a signature and the usages. Both would require additional associations from the usage to the reusable task. E.g. one association to determine which Task to call and one association which Operation to call. |
| Comment by Bruce Silver [ 05/Dec/08 06:12 PM ] |
| If a global task means referenceable, what is the scope of a non-global task? Is it a top-level process? The nearest enclosing subprocess? Or is it available for reference by any caller under the same root element? |
| Comment by Stephen White [ 09/Jan/09 07:33 PM ] |
|
I think that this issue should be raised to critical.
The Global Task taxonomy is not included in the spec and only partly in the MM. Only GlobalTask, GlobalBusinessRuleTask, and GlobalScriptTask exist. I also agree that we should not duplicate the taxonomy. However, Global Tasks are Calleable Elements and not Activities. I'm not sure how we can resolve this. |
| Comment by Stephen White [ 09/Jan/09 07:34 PM ] |
| I raised this to critical since it is a big gap in the spec and MM |
| Comment by Dave Ings [ 14/Jan/09 05:18 PM ] |
| 271 open, assign to Steve, will require spec text as well as metamodel adds may also need metamodel refactoring (which would be hard to do at this stage) |
| Comment by Ivana Trickovic [ 09/Mar/10 07:31 AM ] |
|
As per March F2F Meeting:
- Not agreed that we need to make all tasks global (e.g. global service task) - Agreed to make no changes to the specification and close (out of scope) - This issue is not critical. Change the priority "minor" |
[BPMNFTF-472] [OMG 14798] General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Trivial |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-83 ##Original Info: (Severity: Significant - Nature: Revision) Section(s) of Spec: Throughout Raised by: Matthias Kloppmann Sub-Team responsible: Metamodel Type: Technical Description of issue: The meta-model contains attributes that are conceptually enumerated types. Sometimes their set of values needs to be extensible, sometimes their set of values is closed within the scope of the spec. The spec needs a consistent approach for both types of enums. Proposal: Presumably, enums with a closed list should be defined as enums in the metamodel, while enums that are extensible should be defined as string. Better ways to render this may exist. The outcome of the decision must be applied consistently throughout the spec. ##Proposed Resolution: Close; No Change The FTF has reviewed the list of attributes through the resolution of multiple issues. No further work is required on this topic. |
| Comments |
| Comment by Stephen White [ 10/Jun/09 11:56 AM ] |
| Overall this was done in preparation for the final submission, but it would be a good idea for the FTF to do a final check. |
| Comment by Stephen White [ 19/Mar/10 06:16 PM ] |
| New Proposed Resolution |
[BPMNFTF-471] [OMG 14782] Enabling multiple events at the same time for the same message.
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-256 ##Original Info: (Severity: Significant - Nature: Revision) When multiple message events for the same message (payload type) are enabled at the same time ("executed" at the same time), can they receive the same transmitted message? For example, suppose a process has parallel gateways resulting in two message events for an Order message being executed at the same time. If an order message is sent at execution time, can it be received by both message events? ##Proposed Resolution: Fixed Change text in section "14.2.3 Task": Current: Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When the Message arrives, the Receive Task completes. New: Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When a message with the right correlation information for that process instance arrives, the Receive Task completes. For key-based correlation, only a single receive for a given correlation key can be active, and thus the message matches at most one process instance. For predicate-based correlation, the message can be passed to multiple receive tasks. Change text in section "14.4.2 Intermediate Events" Current: For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flow leaving the Event is followed as usual. New: For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flow leaving the Event is followed as usual. For intermediate message catch events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". Change text in section "14.4.3 Intermediate Boundary Events" Current: For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. New: For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. For intermediate boundary message events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". Change text in section "14.4.4 Event Sub-Processes" Current: A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. New: A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. For Event Sub-Processes triggered via message start events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". |
| Comments |
| Comment by Conrad Bock (NIST) [ 15/Dec/08 08:37 AM ] |
| Open and assigned to Hagen, per status review meeting. |
| Comment by Matthias Kloppmann (IBM) [ 09/Feb/09 07:13 AM ] |
|
This depends on the kind of event, and most importantly, which kind of correlation applies to it.
We distinguish between key-based and predicate-based correlation. For key-based correlation, a particular received message will always match a single receive. Actually, issuing the second receive with the same correlation key should already trigger a (runtime) fault -- this may currently not be specified at this level of detail in the spec though. This is the behavior we know from existing runtimes, and scenarios. For predicate-based correlation, we allow for weaker matching criteria, and consequently, the ability for a single received message to match more than a single receive -- regardless of those receive events residing within a single process instance, or within multiple process instances. Karsten may want to comment further on predicate-based correlation. |
| Comment by Hagen Volzer [ 13/Jul/09 08:55 AM ] |
| My understanding is that the above distinction is made by the current spec, but the distinction could be better reflected by the execution semantics section. Hence I propose to move this forward to FTF as an editorial issue. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:15 PM ] |
|
As per March F2F Meeting:
- A clarification how the second receive behaves to be added. - Assign issue to Matthias |
| Comment by Stephen White [ 24/Mar/10 03:24 PM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:36 AM ] |
|
Proposal:
------------------------------------------------- Change text in section "14.2.3 Task": ------------------------------------------------- Current: Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When the Message arrives, the Receive Task completes. New: Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When a message with the right correlation information for that process instance arrives, the Receive Task completes. For key-based correlation, only a single receive for a given correlation key can be active, and thus the message matches at most one process instance. For predicate-based correlation, the message can be passed to multiple receive tasks. ------------------------------------------------- Change text in section "14.4.2 Intermediate Events" ------------------------------------------------- Current: For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flow leaving the Event is followed as usual. New: For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flow leaving the Event is followed as usual. For intermediate message catch events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". ------------------------------------------------- Change text in section "14.4.3 Intermediate Boundary Events" ------------------------------------------------- Current: For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. New: For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. For intermediate boundary message events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". ------------------------------------------------- Change text in section "14.4.4 Event Sub-Processes" ------------------------------------------------- Current: A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. New: A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. For Event Sub-Processes triggered via message start events, the message correlation behavior is the same as for receive tasks -- see section "14.2.3 Task". |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:36 AM ] |
| newProposedResolution |
| Comment by Gary Brown [ 28/Apr/10 12:55 PM ] |
|
The sentence "For key-based correlation, only a single receive for a given correlation key can be active, and thus the message matches at most one process instance." implies that a process instance could not have concurrent receive activities for different message types with the same correlation key.
Is this restriction intended? |
[BPMNFTF-470] [OMG 14787] Reuse of processes in orchestration and choreography
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
bpdm-tutorial-2-reuse.pdf
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-229 ##Original Info: (Severity: Critical - Nature: Revision) Modelers should be able to define processes independently of whether they will be reused in processes or choreographies. Currently the information coming in or out of a process is either through data flow or through messages, I understand it. The modeler must commit to one of these in advance, or define two copies of the process, one with messages, the other with data flow. Suzette brought this up separately and says a solution was agreed that Mariano will write up. Didn't see any issue from her on this, sorry if this is a duplicate. ##Proposed Resolution: Fixed In section 10.3.2 Executions Semantics for Data, add the following text at the end of the section: --- In the case of Throw and Catch Events, given their nature, the execution semantics for data is different. When a ThrowEvent is activated, all DataInputAssociations of the event are executed, filling the DataInputs of the Event. Finally DataInputs are then copied to the elements thrown by the event (Messages, Signal, etc). Since there are no InputSets defined for Events, the execution will never wait. When a CatchEvent is activated, DataOutputs of the event are filled with the element that triggered the event. Then all DataOutputAssociations of the event are executed. There are no OutputSets defined for Events. To allow invoking a Process from both a CallActivity and via MessageFlow, the StartEvent and EndEvent support an additional case. In the case of a StartEvent, the DataInputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process DataInputs can be filled using the elements that triggered the StartEvent. In the case of a EndEvent, the DataOutputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements of the EndEvent can use the Process DataOutputs as sources. |
| Comments |
| Comment by Stephen White [ 03/Oct/08 05:22 PM ] |
|
Not sure I agree with this. Processes and Choreographies are quite different. There are some common elements, such as Events, Gateways, etc. and these are packaged in the Core::Common packaged. Messages are one of these common elements are can be used in both.
I don't see any re-use across Process and Choreo. Processes are restricted within Pools and Choreos are only between Pools, Also the activities of Choreo and Process are quite different, with different attributes. Data can be used in Processes but not Choreos. Furthermore, the end users of Process and Choreo are quite different (at least for now), and there shouldn't be any confusion as to what those end users are modeling. For Process modelers, if they create Process(es) within a Collaboartion (with Pools), then a Choreography could be derived, at least in part. |
| Comment by Conrad Bock (NIST) [ 04/Oct/08 11:36 AM ] |
|
The business modeler will mostly see similarities. Information comes
into the process and goes out. It might be from/to someone in the same department or a different one, from the same company or a different one, depending on the usage. The modeler doesn't want or need to commit to where the information is going to or coming from when they define the process (or maintain two versions of the process, as Suzette pointed out). This was brought up independently by the information architects at NASA and other places. These domain experts aren't wedded to a particular metamodel or arbitrary rules of particular notations. My understanding is Mariano has a solution based on using Message Events in both cases. |
| Comment by Stephen White [ 06/Oct/08 02:07 PM ] |
|
I think that the issue really has to do with Process vs Collaboration, not Choreography -- in BPMN terms.
I can see how high level models may not care about who is doing what activity. Thus, the distinction betwen Lanes and Pools in not imporant. When Pools are introduced (which brings us to a Collaboration), then there is an concern about data vs. message and there might be some reuse there. However, I don't think that there is an "automatic" way to introduce Pools and create a Collaboration from a set of Lanes. There is most likely human involvement in the conversion. Some MM structuring could help with whatever conversion can be automated, though. Choreography is a different animal. |
| Comment by Conrad Bock (NIST) [ 06/Oct/08 02:30 PM ] |
|
Sorry, I must not have been clear. There is no introduction of lanes and
pools in the use case I'm referring to. The modeler is just defining a reusable process. They don't know if it will be reused later (by some other modelers) as a subprocess of another process, or as a process "realizing" a participant in a choreography. The modeler is forced to define the process with tasks sending and receiving messages for providing and receiving information from/to the process, or with dataflow for providing and receiving information. This limits how the process can be reused, because message tasks won't work if the process is reused as a subprocess, and dataflow won't work if the process is reused by realizing a participant. The model currently "early binds" the decision about how the process will be used. |
| Comment by Suzette Samoojh (IBM) [ 08/Oct/08 03:48 PM ] |
|
Just noticed this issue, so figured I would provide my 2 cents. I've asked Mariano for a pointer to the JIRA issue he's using for his write-up (I couldn't find it either). In the meantime, here are my thoughts/opinions.
1. I agree with Conrad. I as a user simply want to state that my process requires X as input. I don't know whether X will come in as a Message (when I'm participating in a Collaboration) or whether X will come in as pure data (when my process is simply being called from another process). I should be able to define a single process that could be used in either situations. [This is very very common amongst tool users ... they want to define a single library of models that could be reused in different situations]. 2. We discussed this in the data modeling breakout during the F2F. Mariano volunteered to write-up the proposal. But the net is that a MessageStartEvent would be able to either receive a Message (the Collaboration scenario), or its data requirements can be fulfilled through an associated DataInput (the Reuse scenario). But we should wait for Mariano's write-up to get the full details. |
| Comment by Suzette Samoojh (IBM) [ 08/Oct/08 04:03 PM ] |
| There is existing JIRA issue for this topic, so we'll use this one. Assigning to Mariano (assuming he is still volunteering). |
| Comment by Mariano Benitez (Oracle) [ 08/Oct/08 04:28 PM ] |
|
Yep, we agreed to allow (somehow) processes to use the same definition whether they are invoked via a direct call or a message. I am still catching up with JIRA, I just came back from a 3 weeks road show... Thanks for reminding.. :)
If my memory still keeps some data, the proposal we arrived is that a MessageStartEvent is implicitly defined as a DataInput for the process. Since a process is a callable element, we assume they have data inputs and input sets, but we still need to clarify how those things are mapped to the inner elements (the message start event, or anything else?) |
| Comment by Mariano Benitez (Oracle) [ 08/Oct/08 04:29 PM ] |
|
and yes, I will work on a proposal for this. :)
|
| Comment by Stephen White [ 08/Oct/08 08:41 PM ] |
|
I just want to clarify the terminology. A process that applies to a participant would never be realized in a Choreography. It can be realized in a Collaboration, through a Pool. That process may or may not conform to a choreography, which is a different type of model. There can be no re-use between Processes and Choreographies.
So the issue is about the use of a Process (or parts of a Process) within or between Participants in a Collaboration. In that case, the differences between data flow and message flow becomes important. |
| Comment by Conrad Bock (NIST) [ 09/Oct/08 09:44 AM ] |
|
The modeler needs to declare which processes "realize" participants in
which choreographies (in part to record how it satisfies a legal commitment to other companies). It seems like creating a collaboration is alot for such a simple thing, and the collaboration model exposes the internals of the process, which might not be desirable on interchange. |
| Comment by Stephen White [ 14/Oct/08 01:24 PM ] |
|
We are not providing any formal mechanisms that would enable a modeler to declare that a process actually "realizes" a choreography. Using a Choreo within a Collaboratiion is way that a modeler can visualize the relationship between the internal Process and the Choroegraphy, but it does not guarantee conformance.
Such a conformance validation would be useful, but is not a part of our spec. It will have to be done sepaately. For the Processes shown in the Collaboration (within Pools), they do not have to show any internal behavior. They could be Abstract Processes, showing only the touch points. Whether they show internals or not is up to the modeler. |
| Comment by Conrad Bock (NIST) [ 14/Oct/08 01:45 PM ] |
|
There must be a connection between process and choreographies the
modeler is expecting the processes to support. This doesn't mean automatically checking that they do support the choreographies, only that the modeler can say what their intention is. Building a collaboration that indirectly points to a choreography is too heavy for such a simple and common end-user need . Will file a separate issue on it. |
| Comment by Conrad Bock (NIST) [ 14/Oct/08 02:15 PM ] |
| See http://www.osoa.org/jira/browse/BPMN-269. |
| Comment by Dave Ings [ 15/Oct/08 04:44 PM ] |
|
As per 10/15 "BPMN Issue Review" meeting: leave as new pending explanatory use cases to be developed by Conrad
|
| Comment by Conrad Bock (NIST) [ 16/Oct/08 01:20 PM ] |
| See attached slides. |
| Comment by Conrad Bock (NIST) [ 03/Mar/09 12:47 PM ] |
|
Another example related to Steve's is at
http://www.osoa.org/jira/browse/BPMN-390, with expanded and collaposed interactive subprocesses: http://www.osoa.org/jira/secure/attachment/10204/Proposal+for+DI+issue+on+Pages.doc http://www.osoa.org/jira/secure/attachment/10315/10315_BPMN-390-example-1%262.JPG |
| Comment by Dave Ings [ 06/Mar/09 02:26 PM ] |
| Deferring as per 3/5 choreo status call minutes. |
| Comment by Conrad Bock (NIST) [ 02/Apr/09 08:59 AM ] |
|
Here's some user support for addressing this issue:
> [Paul Harmon] We worry that teaching the distinction between a solid > and a dotted arrow is too confusing and might better be omitted. From user input to OMG/BMI, see http://www.omg.org/archives/bmi/msg01227.html. Typical modelers draw solid lines (item/data flow) across pools to indicate messaging. It isn't necessary to have a separate notation for it. |
| Comment by Ivana Trickovic [ 15/Mar/10 07:53 AM ] |
|
As per March F2F Meeting:
- Add clarification of the issue in a comment. - We agreed on resolution - will be updated. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 02:43 PM ] |
|
The resolution we agreed is the following:
Allow DataAssociation from a StartEvent to target a DataInput of the process. Simetrically with DataAssociation of and EndEvent to target a DataOutput of the process. I see 2 options here as of how to further refine this definition: 1) Do it automagically, when the DataInput has the same name and type as the one in the StartEvent (the message normally). 2) Allow the DataInput to be the target, so you can transform the incoming message into some other structure using transformation expressions in the DataAssociation. To keep it simple, I would be included to the first option, but no strong opinions against any of these. This solution allows a process invoked via a CallActivity to behave the same way as when created using a Message Event. |
| Comment by Suzette Samoojh (IBM) [ 15/Mar/10 03:33 PM ] |
|
I'm not a fan of the first option. It applies conventions we don't have anywhere else. Plus, it's fairly fragile ... all it takes is for the user to accidentally rename one of them to essentially 'break' the model.
A third option: Add a metamodel association between the DataInput and the StartEvent. Essentially, formalizing option 1 in the metamodel rather than relying on name/type conventions. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:58 PM ] |
| proposalScheduledForBallot10 |
| Comment by Mariano Benitez (Oracle) [ 23/Mar/10 02:40 PM ] |
|
Another more refined proposal:
Proposal 1) Currently, the Events MM allow DataInputs (throw event) or DataOutputs (catch event) in Events. The current description states that after the catch event occurs, a data association can copy the data from the event (the message, signal, etc) into a data object of the process (p 243 of draft pdf). Consequently there is no need for the data input and data output of the events , since the data is copied to/from the message directly. So the proposal is to remove data input and data output from events and use event data (messages, signals, etc) as possible source or targets of the data associations in the event. Otherwise prop we need to properly describe how to copy the event data to the data inputs. (I don't like this option) Proposal 2) Include a paragraph for events in section 10.3.2 Execution semantics for Data. Here we include: a) that data associations of the event can use as source or target the data contained in the event definitions (messages, signals, etc) b) Data Associations of a Start Event can also use the process data inputs as valid targets, and the simetric with End Event. c) include a short paragrah explaining that b) is intended to allow a top-level process to be invoked via messages or a call activity. d) describe that in the case of events, there are no inputsets or outputsets, consequently, waiting for data is not supported. Proposal 3) In section 10.3.1 in the section mapping data inputs and outputs of activities (p 226 of beta 1 pdf) add a section for send and receive task specifying behaviour similar to service task (a single data input/output mapped to the event message) So to summarize: - all Tasks use data inputs/outputs (including send and receive, data associations only uses data inputs/outputs) - Events do not use data inputs/outputs (data associations can use as source or target even definition data) - Data Associations of a Start event can use as target a process data input, Data Associations of an End events can use as source a process data output. These are the only places where a process data input can be the target of a data association, or a process data output can be the source of a data association. And one open question: - Do we allow a receive task without incoming sequence flow (= start event) to target the process data inputs? Hope it is clear, waiting for comments, MAriano |
| Comment by Suzette Samoojh (IBM) [ 23/Mar/10 03:59 PM ] |
|
Mariano, please see In there we discuss the fact that the event data cannot be used as the source/target of data associations because they are not ItemAwareElements. And we don't want to make them ItemAwareElements because they'll inherit things like DataState. In |
| Comment by Mariano Benitez (Oracle) [ 23/Mar/10 04:18 PM ] |
|
Right Suzette, thanks for reminding... :)
So I assume that as part of My proposal 2) in section 10.3.2 changes to: a) mention events as well as tasks in this section, following the same procedure (using data inputs) b) c) and d) remains the same. Proposal 3) will be included in BPMN-359. Is this right? |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 10:35 AM ] |
|
New Proposed Resolution
Please review for proper wording and terms. |
[BPMNFTF-469] [OMG 14797] Section 9.2: Pool description needs revisiting
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Meera Srinivasan (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-91 ##Original Info: (Severity: Significant - Nature: Revision) Page 114 (144 in PDF) states that a "Pool acts as the container for a Process". This is not true. Pools simply reference Processes. Proposal: Rewording to something like: A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box". ##Proposed Resolution: Fixed 1) in Page 22 Table 7.1 BPMN Modeling Elements Original Text A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. Append the following to the original text A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box". (2) in Page 144 Section 9.2 - Pool and Participant Replace the following text: Graphically, a Pool is a container for partitioning a Process from other Pools with this: A Pool may or may not reference a Process. |
| Comments |
| Comment by Stephen White [ 11/Sep/09 04:23 PM ] |
| The section and page numbers were updated to match the Beta 1 spec |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 06:59 AM ] |
|
proposalScheduledForBallot10
Meera is helping with these issues |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 12:53 PM ] |
|
Following places need to be updated to reflect this:
(1) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 22 Table 7.1 BPMN Modeling Elements Original Text A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. Add the following to Original Text A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box". (2) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 144 Section 9.2 - Pool and Participant Original Text Graphically, a Pool is a container for partitioning a Process from other Pools Replacement Text A Pool may or may not reference a Process. |
[BPMNFTF-468] [OMG 14783] Semantics for data flow without sequence flow
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Hagen Volzer |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
468-Proposal.rtf
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-255 ##Original Info: (Severity: Critical - Nature: Revision) An activity with data flow input and no incoming sequence flows should be given an executable semantics. Then the modeler can focus on what data activities accept and provide, without the complications of sequencing activities. The semantics could apply when input data is taken only at the beginning of activity execution, and only from output data that is provided at the end of execution of a previous activity in the flow. This isn't the same as sequence flow with associated data, because each incoming token on a sequence flow "enables the activity independently" (see 13.1.1. Sequence Flow Considerations). An inclusive merge semantics for multiple incoming sequence flows (as in http://www.osoa.org/jira/browse/BPMN-117), helps, but doesn't work with mult-token activities or subgraphs in common cases (see http://www.osoa.org/jira/browse/BPMN-254). -----Proposal---------------- F2F 03/09/2010 ------------------------- ##Proposed Resolution: Fixed We propose to relax the sequence flow (SF) connection rules for activities. Any activity may or may not have incoming or outgoing SF, irrespective of the presence of start and end events. The semantics we propose for activities without incoming/outgoing SF is as follows: - each activity that does not have any incoming SF is triggered (ie receives an implicit token) upon instantiation of the containing (sub-) process - each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event. This requires the following changes to the spec document (referring to dtc/2009-08-14 ): in Sect. 10.2 Paragraph "Sequence Flow Connections" - in the sentence "If the Activity does not have an incoming Sequence Flow, and there is no Start Event for the Process, then the Activity MUST be instantiated when the Process is instantiated.", delete "and there is no Start Event for the Process," - in the sentence "If the Activity does not have an outgoing Sequence Flow, and there is no End Event for the Process, then the Activity marks the end of one or more paths in the Process", delete "and there is no End Event for the Process" in Sect. 10.4.2 "Start event", - delete this: "If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at least one Sequence Flow. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation Marker). Compensation Activities MUST NOT have any incoming Sequence Flow, even if there is a Start Event in the Process level. See page 314 for more information on Compensation Activities. u An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary). " Change this: "If the Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated. There is an assumption that there is only one implicit Start Event, meaning that all the starting Flow Objects will start at the same time. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. " into this: "All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. in Sect. 10.4.3 "End event": Delete this: "If an End Event is used, then there MUST NOT be other flow elements that do not have any outgoing Sequence Flow—all other Flow Objects MUST be a source of at least one Sequence Flow. • Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities MUST NOT have any outgoing Sequence Flow, even if there is an End Event in the Process level. See page 314 for more information on Compensation Activities. " In this: "If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e., are not a source of a Sequence Flow) mark the end of a path in the Process. However, the Process MUST NOT end until all parallel paths have completed." delete "If the End Event is not used, then " in Sect. 14.2.1. "Sequence Flow Considerations" change this: "If an Activity has no incoming Sequence Flow, and there are no Start Events in the containing Process or Sub- Process, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are Event Sub-Processes and Activities marked as Compensation Activities, as they have specialized instantiation behavior. " into this: "If an Activity has no incoming Sequence Flow, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are Compensation Activities, as they have specialized instantiation behavior. " change this: "If the Activity has no outgoing Sequence Flow and there are no End Events in the containing Process or Sub- Process, the Activity will terminate and termination semantics for the container applied. " into this: "If the Activity has no outgoing Sequence Flow, the Activity will terminate without producing any tokens and termination semantics for the container is then applied. " |
| Comments |
| Comment by Oliver Kieselbach (SAP) [ 25/Nov/08 08:10 AM ] |
|
I would like to see some examples and use cases which highlights the benefits of that approach compared to what has to be done with the current available concepts. This would help me understand what could be done already based on the meta model and concepts we have, where some refinements are necessary or at which points there would be bigger impact.
E.g. is it possible to solve the use case you have in mind with "visual shortcuts" like we already defined the data flow modeling (see figure 10-45 in spec 0.9.0). If not what impact would such a concept have for the activity lifecycle (e.g. if we define that the input pulls the data..we probably have to define how the output of the prev. activity is still available and when runtimes can destroy the context of activities). |
| Comment by Conrad Bock (NIST) [ 25/Nov/08 03:56 PM ] |
|
My understanding is an activity with multiple incoming sequence flows
annotated with data (the visual short cut you mentioned) results in multiple executions of the activity, each waiting for data inputs necessary to start. A typical data flow without sequence flow executes the activity once when all the data is available. This is very natural for many applications. Requiring sequence flow forces the modeler to introduce parallel merges, which is redundant from the modeler's perspective. The impact on the lifecycle is to make is to do the same data polling it needs to do now to wait for data, as I understand it, except it does this at the start of a process for all activities that have no incoming control flow. |
| Comment by Mariano Benitez (Oracle) [ 15/Dec/08 01:27 PM ] |
|
Conrad,
incoming sequence flows with annotated data is a shortcut for a couple of data associations, one coming out of the source of the SF, and another one coming into the target SF. Even if it is not modeled graphically, the behaviour it is like you described, wait for all the data to become available, regardless of the sequence flow. If a modeler chooses the visual shortcut, and there are multiple incoming SF, he would need to do some further editing to define it properly. Also, you need to remember that "InputSets" define the set of required inputs. Hope it clarifies. MAriano |
| Comment by Hagen Volzer [ 08/Jan/09 03:37 AM ] |
|
I think that drawing a data flow dependency between two activities without control flow is supported implicitly by the spec as of today, at least
for the usual acylic cases without multiple instances. |
| Comment by Dave Ings [ 14/Jan/09 05:19 PM ] |
| 255 leave as new, Conrad to create a motivational use case (or decide that this issue should be closed) |
| Comment by Conrad Bock (NIST) [ 10/Feb/09 02:54 PM ] |
|
I think a simpler way to handle input sets is to allow activities
without sequence flow to start when they have all their required data. Then an activity that needs data from one of the input sets can start when the data is available, see http://www.osoa.org/jira/browse/BPMN-255 http://www.osoa.org/jira/browse/BPMN-365 |
| Comment by Conrad Bock (NIST) [ 10/Feb/09 02:57 PM ] |
|
Sorry, the above comment was meant for
http://www.osoa.org/jira/browse/BPMN-145. |
| Comment by Dave Ings [ 10/Mar/09 03:52 PM ] |
| Deferred with Conrad's agreement. |
| Comment by Stephen White [ 27/Jan/10 06:48 PM ] |
|
-------------------- Discussed during Conference Call on 2010-01-27 ---------------------
Data flow without sequence flow (SF) Should be able to model activities that start when they have necessary inputs, without SF. Normally, the SF just orders when the data arrives. Currently, there are no floating activities when there is a Start Event. Maybe use Ad Hoc? UML semantics? Activities can't run until data inputsets are there. Example: A data to B data to C with no SF. Each will start when the data arrives. Tokens will already be there. There is an issue about relaxing the SF requirement. Issue 267. We might make new issue about relaxing connection requirements, which would solve 267 and 468. or just use 267. 468 activities could be involved in a loop. This complicates things. An Ad Hoc would be needed? Ad hoc has a separate semantics, a generalization of the normal. No restriction on data flow. Talks about a user that selects that activities. No real non-determinism. What happens when a non-user task completes in Ad Hoc. A user is the Ad Hoc engine? Issue 267 will change the semantics so that some activities can be floating. They will be initialized whenever the Process starts. They will run whenever the data arrives. They can't be in a loop, but this is good enough for now. (Maybe Ad Hoc could work). This will be closed when 267 is closed. |
| Comment by Hagen Volzer [ 10/Feb/10 12:16 PM ] |
|
New Proposed Resolution: Fixed
We propose to relax the sequence flow (SF) connection rules for activities. Any activity may or may not have incoming or outgoing SF, irrespective of the presence of start and end events. The semantics we propose for activities without incoming/outgoing SF is as follows: - each activity that does not have any incoming SF is triggered (ie receives an implicit token) upon instantiation of the containing (sub-) process - each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event. This fixes this issue to a large extent. The changes to the spec are detailed in the attached document. Note: This is also related to 267 and we intended to attach this resolution to 267, but after reading Marianos comment there, I suspect that this resolution does not sufficiently address 267. I will add a note there as well. |
| Comment by Tom Rutt [ 22/Feb/10 12:29 PM ] |
|
I am not sure what the statement, from proposed resolution to bpmnftf-468,
" - each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event. " buys us. Why cannot the user just draw the explicit sequence flow to an end event? I also posted a related comment to issue 267. |
| Comment by Hagen Volzer [ 23/Feb/10 02:19 AM ] |
|
Tom,
The phrase just says that there is no semantical difference whether the user draws that end event or not. Less syntactic restrictions. Not more. |
| Comment by Ivana Trickovic [ 09/Mar/10 07:51 AM ] |
|
As per March F2F Meeting:
- Proposal attached in JIRA looks ok (see below the full proposal) - Include this issue proposal in the next ballot Full proposal (from the attachment): We propose to relax the sequence flow (SF) connection rules for activities. Any activity may or may not have incoming or outgoing SF, irrespective of the presence of start and end events. The semantics we propose for activities without incoming/outgoing SF is as follows: - each activity that does not have any incoming SF is triggered (ie receives an implicit token) upon instantiation of the containing (sub-) process - each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event. This requires the following changes to the spec document (referring to dtc/2009-08-14 ): in Sect. 10.2 Paragraph "Sequence Flow Connections" - in the sentence "If the Activity does not have an incoming Sequence Flow, and there is no Start Event for the Process, then the Activity MUST be instantiated when the Process is instantiated.", delete "and there is no Start Event for the Process," - in the sentence "If the Activity does not have an outgoing Sequence Flow, and there is no End Event for the Process, then the Activity marks the end of one or more paths in the Process", delete "and there is no End Event for the Process" in Sect. 10.4.2 "Start event", - delete this: "If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at least one Sequence Flow. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation Marker). Compensation Activities MUST NOT have any incoming Sequence Flow, even if there is a Start Event in the Process level. See page 314 for more information on Compensation Activities. u An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary). " Change this: "If the Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated. There is an assumption that there is only one implicit Start Event, meaning that all the starting Flow Objects will start at the same time. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. " into this: "All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. in Sect. 10.4.3 "End event": Delete this: "If an End Event is used, then there MUST NOT be other flow elements that do not have any outgoing Sequence Flow—all other Flow Objects MUST be a source of at least one Sequence Flow. • Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities MUST NOT have any outgoing Sequence Flow, even if there is an End Event in the Process level. See page 314 for more information on Compensation Activities. " In this: "If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e., are not a source of a Sequence Flow) mark the end of a path in the Process. However, the Process MUST NOT end until all parallel paths have completed." delete "If the End Event is not used, then " in Sect. 14.2.1. "Sequence Flow Considerations" change this: "If an Activity has no incoming Sequence Flow, and there are no Start Events in the containing Process or Sub- Process, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are Event Sub-Processes and Activities marked as Compensation Activities, as they have specialized instantiation behavior. " into this: "If an Activity has no incoming Sequence Flow, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are Compensation Activities, as they have specialized instantiation behavior. " change this: "If the Activity has no outgoing Sequence Flow and there are no End Events in the containing Process or Sub- Process, the Activity will terminate and termination semantics for the container applied. " into this: "If the Activity has no outgoing Sequence Flow, the Activity will terminate without producing any tokens and termination semantics for the container is then applied. " |
[BPMNFTF-467] [OMG 14777] Correlation across conversations
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-288 ##Original Info: (Severity: Critical - Nature: Revision) The metamodel seems to be missing relations between the correlation information in multiple conversations of the same collaboration / choreography. For example, in Figure 11.3 (Conversation diagram depicting several conversations between Participants in a related domain) how does the process internal to Consignee handling the Consignee-Retailer conversation map its correlation information to the correlation info in the Consignee-Supplier conversation? Without this the Consignee conversations with the Retailer and Supplier will be uncoordinated. |
| Comments |
| Comment by Conrad Bock (NIST) [ 27/Oct/08 02:07 PM ] |
| Ivana said she will check with Alistar before opening this. |
| Comment by Conrad Bock (NIST) [ 16/Dec/08 10:58 AM ] |
|
Ivana said: Please check v0.9.2 and in particular the cardinality condition on
conversation and correlation set. |
| Comment by Conrad Bock (NIST) [ 16/Dec/08 02:36 PM ] |
|
I see that conversations can have multiple correlation sets, but where
is the mapping specified between them? For example, in Figure 9.13 of v0.9.2 (A Conversation Diagram example), the correlation information specified between Retailer and Consignee might need to be transformed to the correlation information between Consignee and Supplier. Where is that mapping specified? |
| Comment by Dave Ings [ 14/Jan/09 04:47 PM ] |
| 288 open assign to Alistair, probably work in progress and/or already done, Alistair can determine which is the case |
| Comment by Alistair Barros [ 02/Feb/09 11:36 PM ] |
|
Spec updates sent to Steve provide preliminary text to address this issue. technical
discussions are currently taking place and final proposal will be produced as a result. |
| Comment by Conrad Bock (NIST) [ 11/Feb/09 09:18 AM ] |
|
Alistar, I couldn't find this addressed in the update posted on
http://www.osoa.org/jira/browse/BPMN-253, maybe I missed it. Since a conversation provides a multi-participant view, the message flows between two of the participants might contain information used for correlation with other participants. For example, in the conversation in Section 1.7 of your update, a message flow from Retailer and Consignee might have data to be used as correlation information between the Consignee and Supplier and back to the Retailer from the Supplier. This enables the Retailer to tell the message flows from the Supplier are apart of the overall interaction involving the Consignee. How are these relationships between the conversations captured in the metamodel? |
| Comment by Dave Ings [ 06/Mar/09 02:33 PM ] |
| Deferring as per 3/5 choreo status call minutes. |
| Comment by Ivana Trickovic [ 11/Mar/10 07:45 AM ] |
|
As per March F2F Meeting:
Proposal is to close the issue (not a problem) with no changes to the specification. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:47 AM ] |
|
From: Stephen A White
Sent: Thu, March 18, 2010 8:25 PM Ivana, Mariano, [snip] We had only one comment about Ballot 9 issues. Issue 467, one of Alistair's issues, is set to close; no change. We might be ok with that disposition, but we don't understand the reasoning behind it. The disposition says that it "is not a problem with the specification, so we close with no change." This is not explained and we think there is still a gap in the spec. We weren't at the F2F so we don't know what was discussed. We don't know how the gap may be filled with the current spec. So we would ask for an explanation, preferably in the resolution. (This should be a general rule. Although it requires more work, it helps the readers of the issue understand the resolution). Otherwise, we would like it deferred for an RTF to handle. -Steve |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:48 AM ] |
|
From: Mariano Benitez
Sent: Thursday, March 18, 2010 7:59 PM It is my default description for that, this means we did not.write a full reason for it. If the team considers ok to defer, I do not have an issue. |
| Comment by Stephen White [ 22/Mar/10 03:36 PM ] |
| Reduced Priority from Critical to Major |
| Comment by Conrad Bock (NIST) [ 22/Mar/10 03:41 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 01:19 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Defer The issue points out that properties of correlation keys in different conversations might be intended to have the same runtime values, but this cannot be currently captured in the metamodel. For example, in Figure 11.3 of the beta specification, the conversation between Consignee and Supplier might use some of the same key properties as the conversation between Supplier and Shipper, and these might or might not be intended to have the same value, but the metamodel cannot capture which is intended. This issue is deferred to RTF for more discussion on how to address it. |
[BPMNFTF-466] [OMG 14805] Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| File Attachments: |
Update to Figure 12.6.jpg
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-49 ##Original Info: (Severity: Significant - Nature: Revision) Section(s) of Spec: 12.4.1, subsec "Choreography", p. 316 (pg 346 in PDF). Raised by: Matthias Kloppmann Sub-Team responsible: Choreo Type: Technical Description of issue: The text reads "A choreography task ... represents a coherent set of Message exchanges." Neither "coherent" nor "set" is further detailed, nor is a schema shown that clarifies the relationship between Choreography Task and Message Flow. Proposal: Provide further explanation of "coherent set", and provide meta-model for Choreography Task. ##Proposed Resolution: Duplicate The resolution of issue 14890 will resolve this issue |
| Comments |
| Comment by Stephen White [ 05/Mar/09 07:26 PM ] |
|
The technical aspect of this issue was handled by Issue 444.
The remaining text updates are editorial. The issue will be placed in the Editorial component. |
| Comment by Stephen White [ 11/Sep/09 01:12 PM ] |
| The section and page number and section were updated to match the Beta 1 Spec |
| Comment by Gary Brown [ 25/Jan/10 04:19 AM ] |
|
The proposal needs to be adjusted to take into account the resolution of |
| Comment by Mariano Benitez (Oracle) [ 08/Feb/10 11:36 AM ] |
|
------------------------ Withdrawn Proposed Resolution ----------- 2010-01-22 ----------------------------
(a) Section 12.4.1, page 316 (346 pdf), first paragraph, second sentence: change "which is a coherent set (1 or more) of Message exchanges" to "which is one (1) or more Message exchanges" (b) Section 12.4, page 315 (345 pdf), Figure 12.6 shows the metamodel for Choreography Task, but needs to be updated as shown in the attached figure ------------------------------------------------------------------------------------------------------------------------ |
| Comment by Stephen White [ 19/Mar/10 06:23 PM ] |
| New Proposed Resolution |
[BPMNFTF-465] [OMG 14799] Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Tammo van Lessen |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-activities_TL.doc
10_process-activities_TL_v2.doc
10_process-gateways_TL.doc
14_execsem_TL.doc
14_execsem_TL_v2.doc
Instantiate Receive Task.vsd
New Icon for Instantiating Receive Task.jpg
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-72 ##Original Info: (Severity: Significant - Nature: Revision) Section(s) of Spec: 8.4.1 and 8.4.6 Raised by: Matthias Kloppmann Sub-Team responsible: Type: Technical Description of issue: Section 8.4.1 states that a gateway's behavior is performed at instantiation time of the process if there is a gateway with no incoming sequence flow (top of p. 126). However, section 8.4.6 introduces an "instantiate" flag for Event-base Gateways, which seems to have the exact same purpose (table 8-85 on p. 128). These two ways of tying process instantiation and gateway execution together need to be reconciled. Proposal: Preferably, get rid of the instantiate flag and allow the behavior described in 8.4.1 for all gateways, including the event-based gateway. Alternatively, introduce an instantiate flag for all gateways (or for those where it makes sense), and describe the relationship between no incoming sequence flow and the flag. ##Proposed Resolution: Fixed Section 10.2.3, Sub-Section Receive Tasks, page 139 (169 pdf): (a) delete the three bullets on page. (b) Third paragraph: replace the second sentence of the paragraph with the following: "In order for the Task to instantiate the Process its instantiate attribute must be set to true and it must not have any incoming Sequence Flow." (c) Last paragraph on page: add the following to the paragraph: "If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as shown in Figure 10.X)." (d) Add new figure after Figure 10.15 that shows the instantiate version of the Receive Task (see http://www.osoa.org/jira/secure/attachment/10698/10698_New+Icon+for+Instantiating+Receive+Task.jpg ), which is a Task with a marker that looks like a small Message Start Event. (e) The new Figure will have the following caption: "A Receive Task Object that instantiates a Process" (f) Table 10.10, second row, second column: delete "after the Start Event or a starting Task if there is no Start Event" Section 10.5.6: (g) Delete the first three bullets after Figure 10.114 (h) First paragraph after Figure 10.114: replace "meet one of the following conditions:' with "not have any incoming Sequence Flow." Section 14.1, Second paragraph, First sentence: (i) Replace "Event-Based Gateway" with "Event-Based Gateway or a Receive Task" (j) Replace "Instantiate flag is true" with "instantiate flag set to true" (k) Section 14.2.3, Bullet for Receive Task: Add the following to the bullet: "If the Receive Task's instantiate attribute is set to true, the Receive Task itself can start a new Process instance." |
| Comments |
| Comment by Hagen Volzer [ 13/Jul/09 10:10 AM ] |
| The spec should clarify the use cases of the "instantiate" flag. Hence I suggest to move this issue to the FTF. |
| Comment by Stephen White [ 13/Jul/09 12:37 PM ] |
|
In V0.9.14 the sections cited above are now 10.5.1 and 10.5.6, respectively.
Section 10.5.1 says: "If the Gateway does not have an incoming Sequence Flow, and there is no Start Event for the Process, then the Gateway's divergence behavior, depending on the type of Gateway (see below), SHALL be performed when the Process is instantiated." This means that the start of the process is not explicitly defined. When the Process is started, however that is done, then the Gateway is handled. It was not intended to indicate that the Gateway was the mechanism for instantiating the Process. The instantiate flag is part of the Event Gateway since that GW can be used to instantiate a Process (when it is the first non Start Event element). We applied Issue 442 to be sensitive to that flag (by changing the notation). We can use this issue to clarify the text. |
| Comment by Tammo van Lessen [ 18/Mar/10 07:28 AM ] |
| proposalScheduledForBallot11 |
| Comment by Tammo van Lessen [ 07/Apr/10 11:13 AM ] |
|
Proposal uploaded.
Summary of changes (as agreed in a former process orchestration call): - No start event allowed before instantiating Receive Task or Event Gateway (i.e. no incoming sequence flow allowed). - New stencil for Receive Task with instantiate=true (Envelope looks like a msg start event) - 14.1 mentions the Receive Task as possible way to instantiate a process model. |
| Comment by Tammo van Lessen [ 07/Apr/10 11:14 AM ] |
| Steve's stencil for Instantiate Receive Task attached. |
| Comment by Tammo van Lessen [ 07/Apr/10 11:35 AM ] |
| revised documents attached. |
| Comment by Tammo van Lessen [ 07/Apr/10 11:41 AM ] |
|
The attachments to be considered are:
- 10_process-activities_TL_v2.doc (579 kb) - 10_process-gateways_TL.doc (216 kb) - 14_execsem_TL_v2.doc (158 kb) - File Instantiate Receive Task.vsd (39 kb) |
| Comment by Tammo van Lessen [ 07/Apr/10 11:41 AM ] |
| New proposed resolution |
| Comment by Tammo van Lessen [ 17/May/10 01:16 PM ] |
|
Spec-Draft3-review
On page 484, 2nd paragraph, the "Instantiate flag" should be lowercase ("instantiate"). Everything else looks good. |
| Comment by Stephen White [ 17/May/10 11:31 PM ] |
| Done |
[BPMNFTF-464] [OMG 14802] Section 10.2 Clearer separation between conceptual and visual model needed
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-60 ##Original Info: (Severity: Minor - Nature: Revision) Section(s) of Spec: 10.2 throughout Raised by: Matthias Kloppmann Sub-Team responsible: Type: Technical Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed. -- p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process" -- p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation. -- p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle" ##Proposed Resolution: Defer This issue can be handled by and RTF. |
| Comments |
| Comment by Ivana Trickovic [ 09/Sep/08 05:36 AM ] |
| This is an editorial issue. |
| Comment by Stephen White [ 11/Sep/08 08:20 PM ] |
| To be discussed during Redwood Shores F2F (Sept. 2008) |
| Comment by Stephen White [ 11/Sep/09 01:30 PM ] |
| The Section and Page numbers were updated to match the Beta 1 spec. |
[BPMNFTF-463] [OMG 14786] Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Hagen Volzer |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Hagen Voelzer, HVO@zurich.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-235 ##Original Info: (Severity: Minor - Nature: Revision) The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:49 PM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 19/Apr/10 06:44 AM ] |
|
##Proposed Resolution: Defer
This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification. |
[BPMNFTF-462] [OMG 14804] Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Gary Brown |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-50 ##Original Info: (Severity: Minor - Nature: Revision) Section(s) of Spec: 8.3.15, table8-56, page 95 (page 125 PDF). The attributes minimum and maximum are mandated to have a min value of 2. Why would multiplicities such as 1..2 be excluded? Couldn't there even be optional participants? Proposal: At the very least, the minimum attribute should allowed to have a minimum of 1. Possibly, minimum should be allowed to start at 0, and maximum at 1. |
| Comments |
| Comment by Stephen White [ 11/Sep/09 01:19 PM ] |
| The section, table, and page numbers were updated to match the Beta 1 Spec. |
| Comment by Stephen White [ 19/Mar/10 06:27 PM ] |
| proposalScheduledForBallot11 |
| Comment by Gary Brown [ 30/Mar/10 11:53 AM ] |
|
##Proposed Resolution: Fixed
8.3.15 Participants p94 "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multi- instance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band of a Choreography Activity (see page 356)." change to: "The multi-instance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41), or the Participant Band of a Choreography Activity (see page 356), when the ParticipantMultiplicity is associated with the Participant, and the maximum attribute is either not set, or has a value of two (2) or more." Table 8.56 ParticipantMultiplicity attributes Change from "minimum: integer [0..1] = 2" to "minimum: integer = 0" - mandatory with default value of 0 with suitable update to schema. "The minimum attribute defines minimum number of Participants that MUST be involved in the Collaboration. The value of minimum MUST be two (2) or greater." change to: "The minimum attribute defines minimum number of Participants that MUST be involved in the Collaboration. If a value is specified in the maximum attribute, it MUST be greater or equal to this minimum value." Change from "maximum: integer [0..1] = 2" to "maximum: integer [0..1] = 1" - optional with default value of 1. "The maximum attribute defines maximum number of Participants that MAY be involved in the Collaboration. The value of maximum MUST be two (2) or greater." change to: "The maximum attribute defines maximum number of Participants that MAY be involved in the Collaboration. The value of maximum MUST be one (1) or greater, AND must be equal or greater than the minimum value." |
| Comment by Gary Brown [ 30/Mar/10 11:54 AM ] |
| New Proposed Resolution |
[BPMNFTF-461] [OMG 14801] Section 10.2.3 ScriptTask.scriptLanguage needs to specify format
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-64 ##Original Info: (Severity: Minor - Nature: Revision) Section(s) of Spec: 10.2.3 Script task Raised by: Matthias Kloppmann Sub-Team responsible: Type: Technical Description of issue: The scriptLanguage is currently specified to be a String, this risks clashes across different implementations. It should either be required to be an URI, or an example should suggest this to be an URI. ##Proposed Resolution: Fixed 1. expressionLanguage, typeLanguage a. Spec tables 8.1 (Definitions), 8.44 (FormalExpression) Add the following to the descriptions for the expressionLanguage and typeLanguage attributes: "The language must be specified in a URI format." There are no changes to the XSD or UML metamodel. 2. scriptLanguage a. Change the name of the attribute to "scriptFormat". Applies to the XSD, UML metamodel, and spec (table 10.10). b. The type of the attribute will consistently be "string". Impacts the XSD only. The UML metamodel and spec currently use "string". c. Replace the description of the attribute in table 10.10 with: Defines the format of the script. This attribute value must be specified with a mime-type format. And it must be specified if a script is provided. d. Replace figure 10.10 e. Update the XSD snippet in table 10.35 |
| Comments |
| Comment by Martin Chapman [ 24/Sep/08 08:06 AM ] |
| we need to be consistent with expression language and type language, so this issue should be considered for all three. |
| Comment by Tammo van Lessen [ 08/Feb/10 10:26 AM ] |
|
I agree with Matthias, however I'm not sure if an URI is the best resolution.
Having a look at other standards, e.g. HTML, their scripting features employ mime-types instead of URI for identifying script languages (e.g application/ecmascript). I think it makes sense to adopt this approach as we could reuse the mime types defined by IANA for many scripting languages. Regarding the expression language and type language, I think these fields are different and tighter integrated into BPMN so that it probably makes sense to use IRIs and a standard set of IRIs directly put into the spec to identify the most prominent languages/types. BPEL can serve as an example in this case. |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 12:21 PM ] |
|
The scriptLanguage, expressionLanguage, and typeLanguage are already of type "anyURI" in the XSD. However, the spec text (tables of attributes) states that these are of type "string" and does not further describe a required format (other than providing default values, which are in URI format and thus serve as an implied format). Also note that there is no built-in UML type that is equivalent to "URI" (at least not that I can find), and so in the MM they would have to remain as "string' type.
Tammo's recommendation makes sense to me. So, I plan to proceed as follows: expressionLanguage, typeLanguage - No XSD changes, no MM changes. - Add the following to the spec text: The language must be specified with a URI format. scriptLanguage - Change the name of the attribute to "scriptFormat" (to differentiate from usages of 'languages' which are of type URI). Update the MM and XSD to match. - Further modify the XSD, changing the scriptLanguage attribute from type "anyURI" to "string". - Further modify the spec text to state that the attribute must be specified using the mime-type format. |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 12:39 PM ] |
|
-------------------------------------------------------------------------------------
Proposed Resolution: Fixed 1. expressionLanguage, typeLanguage a. Spec tables 8.1 (Definitions), 8.44 (FormalExpression) Add the following to the descriptions for the expressionLanguage and typeLanguage attributes: The language must be specified in a URI format. There are no changes to the XSD or UML metamodel. 2. scriptLanguage a. Change the name of the attribute to "scriptFormat". Applies to the XSD, UML metamodel, and spec (table 10.10). b. The type of the attribute will consistently be "string". Impacts the XSD only. The UML metamodel and spec currently use "string". c. Replace the description of the attribute in table 10.10 with: Defines the format of the script. This attribute value must be specified with a mime-type format. And it must be specified if a script is provided. d. Replace figure 10.10 e. Update the XSD snippet in table 10.35 |
| Comment by Pete Rivett [ 28/Apr/10 07:27 PM ] |
| Though the proposed resolution specifies the format as 'mime-type' it does not say how it will be interpreted, nor the values to be used for script languages that are not registered with IANA. |
| Comment by Suzette Samoojh (IBM) [ 03/May/10 10:46 AM ] |
|
Discussion in the FTF meeting on May 3, 2010:
- Pete has a good point. But at this time it is difficult to say what formats and languages will be widely used. If we attempted to address this now, it would be based largely on speculation and guess-work. We need time to collect data and feedback so we can enhance the proposal further to provide realistic guidance. - The FTF agreed to: - Proceed with the proposal. It is moving the spec in the right direction. - Request a new issue to enhance the spec further to address the topics raised by Pete. This would be tackled in the future, giving us more time to collect the necessary data. |
[BPMNFTF-460] [OMG 14800] Section 10.5 Text duplicated from 8.3.10
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Trivial |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-70 ##Original Info: (Severity: Minor - Nature: Revision) Section(s) of Spec: 10.5 Raised by: Matthias Kloppmann Sub-Team responsible: Type: Editorial Description of issue: The first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced. Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section. ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 04/Nov/08 01:39 PM ] |
| The sections have changed to 10.5 and 8.2.8, respectively. |
| Comment by Stephen White [ 10/Jun/09 11:54 AM ] |
| The section on Gateways in the common section (now 8.3.10) should be made more generic since Gateways apply to both Processes and Choreographies. |
| Comment by Stephen White [ 11/Sep/09 03:38 PM ] |
| Section number were updated to match the Beta 1 Spec |
| Comment by Stephen White [ 19/Mar/10 06:34 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:03 AM ] |
| This is an editorial issue do move it on ballot #12. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-459] [OMG 14781] Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-258 ##Original Info: (Severity: Significant - Nature: Revision) Figure 10-53 describes the class diagram for properties, they have a containment relation with Activity and Process, but not with Events. In the spec text reads: - "Certain flow elements may contain properties, in particular only Processes, Activities and Events may contain Properties" We already agreed that events activities (throw or catch) can contain properties, so we need to add this to the MM and update the diagram ##Proposed Resolution: Fixed Add relation between Properties and Events in the MM and update the diagram 10-53 |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 09/Oct/08 11:45 AM ] |
|
This is not just a metamodel change, nor is it the data metamodel. Reassigning to the events team.
Events team, please: 1. Ensure you agree with the proposal. 2. Validate that the execution semantics still work for events and that nothing is missing. 3. Make the required text changes to the spec (attributes table and such). 4. Let me know when you're ready and I will include in the consolidated metamodel. |
| Comment by Mariano Benitez (Oracle) [ 05/May/09 08:34 AM ] |
|
in version 0.9.11 the figure is Figure 10-51 - Property class diagram. Page 204.
in the XSD events do not have properties either. |
| Comment by Stephen White [ 24/Mar/10 03:25 PM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:39 AM ] |
| Proposal as stated in issue description: add relation between Properties and Events in the MM and update the diagram 10-53 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:39 AM ] |
| newProposedResolution |
[BPMNFTF-458] [OMG 14791] Section 8.2.1 [Service Model] How to model a request-reply use case?
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-169 ##Original Info: (Severity: Significant - Nature: Revision) In BPMN 1.1 there is no way to model a request-reply model based on a single interface operation. Right now we don't have a way to relate a Receive Task and Service/Reply Task that generates the response to the message received. ------------------- Proposal ------------ 2010-02-22 ------------------------ ##Proposed Resolution: Close; No change Close, no Change. The FTF decided that the reported issue does not identify a problem with BPMN 2.0 ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 14/Dec/09 04:00 PM ] |
|
This topic could also have been put in the Process Orchestration component.
Also, this issue should be considered in the context of the SoaML/BPMN work. |
| Comment by Matthias Kloppmann (IBM) [ 11/Feb/10 07:00 AM ] |
|
Given the constructs we now have in 2.0, in particular the ability to refer to an operation from receive and send tasks, why wouldn't the following work to address this issue:
<receiveTask ... operationRef="theRequestResponseOperation" messageRef="theRequestMessage"/> ... <sendTask ... operationRef="theRequestResponseOperation" messageRef="theResponseMessage"/> It is pretty obvious IMO that referring to the same operation in bot the receive and the send task, plus referring to the request and response messages of that operation respectively, identifies exactly that pattern. (I am aware this only addresses the 95% percent case, as in theory there could be two overlapping interactions using the very same operation. For that BPEL introduces the messageExchange element. IMO, it is not required to support that case -- I have never observed it in practice, and it can easily be solved by having two operations with the same signature.) So, this should answer the question asked by the issue, using only capability that is already available in the spec. Consequently, I suggest to close this issue with no action. |
| Comment by Mariano Benitez (Oracle) [ 11/Feb/10 04:37 PM ] |
|
there are at least 3 cases that are not handled by the current spec:
1) when a process uses the same interface/operation both as provider and consumer (let's say the process is a proxy for another service). How do I know I am closing a request or I am starting a new operation? 2) if you receive multiple messages on the same receive task on the same instance (for example quotes from different providers), how can I know which request I am closing? 3) in an asynchronous request-reply case, I would need to manually keep the callback address and include it in the response. This clutters the process with unnecessary details, when the send task could easily be flagged as the response of a receive task. While I agree this is a very important feature, I do not think we can fix it in this FTF, so I recommend we defer it. |
| Comment by Mariano Benitez (Oracle) [ 11/Feb/10 04:38 PM ] |
|
New Proposed Resolution: Defer
I believe it is important, but I do not think we can incorporate the change in our timeframes. |
| Comment by Matthias Kloppmann (IBM) [ 12/Feb/10 08:47 AM ] |
|
I still think we could close no action, here is why:
Ad 1): That can be distinguished, as you can see from my example above. If the sendTask refers to the responseMessage, it sends a reply, if it refers to the requestMessage, it issues a new request. I realize there could be a boundary case where both have the same message, but again that could be easily disambiguated outside of BPMN at the WSDL level. Ad 2): This could happen in an MI activity or a loop -- if the response is within the same MI or loop instance, there is no issue however, as the correlation is clear. If you insist on designing your process such that it causes the problem :-) you can indeed create one that cannot be solved with the current BPMN 2.0 machinery. I argue that practically relevant processes don't do this (I have never seen one), but could be convinced otherwise by a concrete example. So because of that I could be convinced we cannot simply close, but indeed need to defer. Ad 3): That is a question of the capabilities of the underlying infrastructure and whether it provides you with asynchronous interchange at the physical (messaging) level while providing a request/response view at the logical level. There are known cases where this is done in the infrastructure, without a BPM modeler having to worry about this technical stuff. Again, it requires proper correlation of receive and send, which can be done in 95% of the cases, as per my earlier claim :-). |
| Comment by Mariano Benitez (Oracle) [ 12/Feb/10 09:10 AM ] |
|
As a general feeling I don't like to leave to interpretation which case is a request/reply and which is separate invocations. By simply making assumptions that the implementors can figure out by matching messages if it is one case or the other, or worse, by using extensions, do not give a good impression, and I believe request/reply is such a common use case that it is worth explicitly declaring it.
regarding 1) I don't like relying on the WSDL level to help us disambiguate what case are we in (request/reply or separate), there will be times when modelers cannot change the WSDL, so they would be forced to proxy them just to change names? regarding 2) there are cases where you would receive messages in an event sub-process, store the message and the callback address, and finish the sub-process. In the main process, after some time, you could pick all messages, process them and invoke each callback with the result. I can imagine people would model a buying process this way. or even a voting process could be modeled this way. What I mean is that there are cases where the receive and the send are not in the same MI activity or loop. Having read Matthias arguments, I still keep my opinion to defer it. |
| Comment by Matthias Kloppmann (IBM) [ 12/Feb/10 09:19 AM ] |
|
OK -- I agree with your Event subprocess scenario in 2) -- which however requires introduction of a "sender" notation as a first class citizen, as this goes beyond even static correlation within the model -- rather an instance-level construct is needed (you could do this in BPEL only because you can "assign from partner link", thus effectively keeping the endpoint of the sender).
Regarding 1), I wasn't at the WSDL level, but rather at the level of the BPMN entities operation and message, which exist regardless of whether there is an associated WSDL or not. I'd argue that if you are considering something like a request/response operation, you would in particular have to use an "operation", and you'd naturally also use messages with send and receive tasks. So IMO the sceanrio would quite naturally be disambiguated at the BPMN level already. Anyway, I agree that the discussion about how to deal with 2) is needed, is a very special form of request/reply beyond the scope of the FTF, and hence the item should indeed be deferred. |
| Comment by Conrad Bock (NIST) [ 17/Feb/10 12:11 PM ] |
|
Might also use a definitional collaboration with message flow to/from
the send/receive tasks. The message flow could be grouped by a conversation to show they are part of the same request/reply. A business user could do this without understanding interfaces and operations. |
| Comment by Matthias Kloppmann (IBM) [ 22/Feb/10 09:51 AM ] |
| New proposed resolution: Close with no action |
[BPMNFTF-457] [OMG 14796] Section 10.2.3: Task description needs revisiting
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-93 ##Original Info: (Severity: Minor - Nature: Revision) Section(s) of Spec: 10.2.3 Spec version: Beta 1 Raised by: Suzette Samoojh Sub-Team responsible: Type: Editorial Description of issue: The description for Task needs revisiting - States that "A Task is used when the work in the Process cannot be broken down to a finer level of details". This doesn't reflect typical usage. It's not that it cannot be broken down, but rather many users simply choose to not break down further. Users model at the level of detail most appropriate for their needs and the needs of their audience. - States that "Generally, an end-user and/or applications are used to perform the Task when it is executed". What does this mean? A black-box Task is traditionally used for documentation processes, where what the task does is more important than how (whether by an end-user or by an application) it is done. If users know how it should be done then they would use a specialized task (i.e. User Task or Service Task) rather than Task Proposal: Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks. ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 11/Sep/09 04:37 PM ] |
| The sections were updated to match the Beta 1 spec |
| Comment by Stephen White [ 19/Mar/10 06:35 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:03 AM ] |
| This is an editorial issue do move it on ballot #12. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-456] [OMG 14776] Section 8.1.5 [Infra] Import statement description is not clear enough
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-296 ##Original Info: (Severity: Significant - Nature: Revision) The intention of the import statement is to include an ENTIRE file as a namespace, so I can reference elements defined inside that file. The current text says: "The Import class is used when referencing external element, either BPMN elements contained in other BPMN Definitions or non-BPMN elements. Imports must be explicitly defined." It is not clear that you are importing the entire file (ala BPEL). Also, it is not clear what is the meaning of "Imports must be explicitly defined" ##Proposed Resolution: Fixed Change in Table 8.2 Import Attributes, the description of the importType attribute to: "Identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document.The value of the importType attribute MUST be set to http://www.w3.org/2001/XMLSchema when importing XML Schema 1.0 documents, to http://www.w3.org/TR/wsdl20/ when importing WSDL 2.0 documents, and http://schema.omg.org/spec/BPMN/2.0 when importing BPMN 2.0 documents. Other types of documents MAY be supported. Importing Xml Schema 1.0, WSDL 2.0 and BPMN 2.0 types MUST be supported." Note on 2010-04-26: The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be: - http://www.omg.org/spec/BPMN/20100524/MODEL for the semantic model XML Schema - http://www.omg.org/spec/BPMN/20100524/MODEL-XMI for the semantic model XMI - http://www.omg.org/spec/BPMN/20100524/DI for diagram interchange XML Schema - http://www.omg.org/spec/BPMN/20100524/DI-XMI for diagram interchange XMI xsds |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 23/Oct/08 08:50 AM ] |
| open issue: should we allow BPMN 1.1 or less to be imported? Is there a minimal list of supported import types ? XML Schema and BPMN 2.0, anything else? WSDL? BPEL? |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
| Comment by Pete Rivett [ 19/Apr/10 03:42 PM ] |
|
The proposed namespace for BPMN itself violates OMG's guidelines for these - which is date-based.
Are people OK with the fact that this does not distinguish the XMI and XSD serialization of BPMN 2.0? |
| Comment by Mariano Benitez (Oracle) [ 20/Apr/10 04:56 PM ] |
|
Pete, this issue is about the content of the attribute, not the namespace itself. As you said, the namespace is not correct, but that was the case before.
We will open an internal issue to address this topic. (read OMG guidelines, define the proper namespaces and apply it throughout the spec). |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 10:53 AM ] |
|
Steve,
The importType in the import element, when referencing BPMN 2.0 files, should it refer to the namespace we defined for BPMN 2.0 (http://www.omg.org/spec/BPMN/20100524/MODEL, etc) or just http://www.omg.org/spec/BPMN/2.0 as you included in the spec? And do we have to make different imports for XML Schema and XMI? (I see no use of importing XMI definitions into XML Schema definitions) Regards, MAriano |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 10:55 AM ] |
|
Spec-Draft3-review
@all please include the flag text above to indicate the application of this issue requires review |
| Comment by Mariano Benitez (Oracle) [ 12/May/10 04:38 PM ] |
|
I propose to use the following URI for BPMN imports: http://www.omg.org/spec/BPMN/20100524 it uses the date so it will still be valid for new versions, and it does not refer to XML Schema or XMI, since it is not really needed.
This could be an editorial fix. |
| Comment by Mariano Benitez (Oracle) [ 17/May/10 10:26 AM ] |
|
-- Comments from FTF Meeting on 5/17
The final proposal is to use http://www.omg.org/spec/BPMN/20100524/MODEL as the URI to use in the importType attribute. References to "http://schema.omg.org/spec/BPMN/2.0" should change to "http://www.omg.org/spec/BPMN/20100524/MODEL" This requires changes to the following sections: - Table 8.2 - Import attributes -> - Table 8.16 - Reengineer XML Schema - Section 15.2.1 Example - remove the import element with importType BPMNDI (the second import element) |
| Comment by Stephen White [ 17/May/10 11:25 PM ] |
| Done |
[BPMNFTF-455] [OMG 14767] Provide example: Inline Subprocess
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-312 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Description of issue: Missing example for Inline Subprocess Proposal: Add an example showing Inline Subprocess Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 19/Feb/09 12:33 PM ] |
|
Per the 2009.02.19 examples sub-team meeting:
-- This item is related to BPMN-365 |
| Comment by Stephen White [ 18/Mar/10 08:57 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:54 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:06 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-454] [OMG 14765] Provide example: Multi-instance activity
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-320 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section "Examples" under 10.2.7 Description of issue: Missing example for multi-instance activity. Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:58 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:54 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:05 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-453] [OMG 14763] Provide example: Conversation View
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-330 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section 9.5.3 Examples Description of issue: Missing example for Conversation View. Proposal: Add an example showing a conversation view. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Stephen White [ 01/Dec/08 09:45 PM ] |
|
An example has been started. It needs to be finished (including XML).
Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1) |
| Comment by Stephen White [ 18/Mar/10 08:58 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:53 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:04 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-452] [OMG 14764] Provide example: Complex gateway
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Hagen Volzer |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-326 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section 10.5.7 Examples Raised by: Matthias Kloppmann Sub-Team responsible: "Basics" Type: Example Description of issue: Missing example for complex gateway. Proposal: Add an example showing a complex gateway. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:49 PM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 19/Apr/10 06:44 AM ] |
|
##Proposed Resolution: Defer
This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification. |
[BPMNFTF-451] [OMG 14772] Beta 1: Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools.
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Ivana Trickovic |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-301 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 4 of 12 issues submitted by Bruce Silver Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools. What elements and attributes MUST be supported. There can and should be multiple levels here. You don't have to certify it if you are explicit enough and connect it with #3 above. There will be no shortage of available tools that can check compliance. |
| Comments |
| Comment by Bruce Silver [ 05/Dec/08 05:47 PM ] |
|
Multiple issues here.
One is simple, which is conformance as specified as supporting all the elements and attributes of certain packages, where "supporting" means drawing them correctly and providing some means of entering/viewing the attributes. Conformance should also include serialization compliant with the spec and ability to exchange diagrams with other conformant tools via the serialization. That leads to the other, more difficult issue, which is support for execution-related attributes in "modeling". Some of this is related to different interpretations of what "modeling" vs "executable design" means. The majority of BPMN users today are not using it to define even potentially-executable flows; they are just documenting their as-is process. Even in BPM Suites based on BPMN, the "business analyst" mode of the modeling tool does not expose the user to implementation attributes, many of which are currently MUST HAVE in BPMN. That is not useful. I think "modeling conformance" should explicitly enumerate the elements and attributes that must be supported and these should be restricted to "modeling", i.e. what you describe in the "business analyst" mode of real BPMS tools. That is mostly what you can see in the diagram - pools and lanes, node types and markers, connectors, labels for these, and IDs/IDREFs sufficient to hold linked elements together. That's it. It should not require dataExpressions of any kind. |
| Comment by David Marston [ 24/Jan/09 09:45 PM ] |
|
This may be a good application of "levels" of conformance, or perhaps "profiles" if the different situations cannot be arranged hierarchically. For further reading on the topic of how specifications allow variability, see the W3C QAWG Note "Variability in Specifications" at
http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/ |
| Comment by Ivana Trickovic [ 18/Mar/10 10:32 AM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 12/Apr/10 04:30 PM ] |
|
-------------------- Proposal ---------- 2010-04-12 -------------------------------------
##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for OMG 14240 (JIRA |
[BPMNFTF-450] [OMG 14773] Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-300 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 3 of 12 issues submitted by Bruce Silver Enumerate the validation rules of BPMN. Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative. Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next. Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative. -------- New Proposed Resolution ---------- 2010-01-25 -------------------------------- ##Proposed Resolution: Defer The FTF acknowledges the issue and thinks is a good idea to create a normative appendix with the validation rules. Nevertheless, we think it is not possible to properly resolve the issue during the available time of the FTF. So the proposal is to defer it until the RTF, which can begin as soon as the FTF completes the final report. ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 01:19 PM ] |
|
New Proposed Resolution: Defer
While I agree with Bruce's statement, I don't think we can achive the proposed solution in this FTF. I propose we just defer it for now. |
[BPMNFTF-449] [OMG 14770] Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | WS-BPEL Mapping |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-308 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 11 of 12 issues submitted by Bruce Silver Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!) ---------------------- Proposal ------------- 2010-02-16 ------------------------- ##Proposed Resolution: Defer Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF. --------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 16/Feb/10 06:48 PM ] |
|
---------------------- Proposal ------------- 2010-02-16 -------------------------
Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF. --------------------------------------------------------------------------------------------- |
[BPMNFTF-448] [OMG 14762] Provide example: Choreography
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-331 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section 11.8 Examples Raised by: Matthias Kloppmann Sub-Team responsible: Choreography Type: Example Description of issue: Missing choreography example Proposal: Add an example showing a choreography with several choreography activities, based on the existing example. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Stephen White [ 19/Mar/10 06:35 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:52 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:04 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-447] [OMG 14771] Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Notation, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-302 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 5 of 12 issues submitted by Bruce Silver If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram. ("Modeling" means you don't need to see the non-diagram attributes). It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed. |
| Comments |
| Comment by Bruce Silver [ 05/Dec/08 05:29 PM ] |
| In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay. So the temporal semantics are clear from the diagram. The issue is when service task is guarded by data "availability" - whatever that implies. If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram. |
| Comment by Stephen White [ 19/Mar/10 06:36 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:59 PM ] |
| Update the proposed issue resolution to say that this is a request for a new graphical element (enhancement) so the FTF agreed to defer this issue. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:12 PM ] |
|
##Proposed Resolution: Defer
This is a request for a new graphical element. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-446] [OMG 14758] Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..*
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| File Attachments: |
JIRA Issue Workflow.jpg
|
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-350 ##Original Info: (Severity: Significant - Nature: Enhancement) A Data Object can have multiple states at the same time. Change Multiplicity of datastate attribute from 0..1 to 0..* |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 09/Dec/08 05:20 PM ] |
| Steve, what exactly do you mean by "multiple states at the same time"? I can see value in modeling possible states (i.e. the Order is in either PENDING or APPROVED state), which would require changing the multiplicity. But is that what you mean? |
| Comment by Stephen White [ 10/Dec/08 01:00 AM ] |
|
A Data Object could be a JIRA issue, for example. The issue could have states across muliple dimensions. One dimension could be its status, which could be New, Open, Resolved, etc. Another dimension could be whether or not it has been assigned. These could all be defined states (meaning the multiplicity of State would be 0..*).
Instead of requiring the modeler to make complex states, such as "Open Unassigned" for a single state. it would be better to have the modeler create two different states for the Data Object, one that could be for the status and one for th Assignment. So the Data Object could go from "Open, Unassigned" to"Open, Assigned" by changing one of those states, leaving the other the same. It would be easier to track those states this way also. |
| Comment by Mariano Benitez (Oracle) [ 10/Dec/08 04:54 AM ] |
|
Steve, what you are describing are data object attributes for sure. I don't think people would like to model those things as states (which are separated form the data object itself). And people would also want to access this states from expressions and assignments, so states would not be a perfect fit.
What I would find useful is to "externalize" as state some attribute and keep the state and attribute in sync, but I don't think it is relevant to the spec. Nevertheless, if the state is an opaque object, people could use any structure and manipulate it as they need, so I don't think multiple states are needed. |
| Comment by Stephen White [ 12/Dec/08 08:53 PM ] |
|
Mariano, that's a good point. I'm not sure how to differentiate Data Object state(s) with the attributes. The states are generally displayed with the Issue name and help the users track what is going on.
I posted a model of the JIRA Issue Workflow (https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument). Here you can see that the Data Objects (the Issues) are updated throughout the process and their states change in multiple ways. This is what spawned this issue. Take a look and see if this helps you see the issue or what could be done. |
| Comment by Mariano Benitez (Oracle) [ 15/Dec/08 07:57 AM ] |
|
Steve,
The JIRA example you are using is borderline between executable and non-executable processes, which creates some confusion on the intention. I have a couple comments regarding your use case (JIRA Issue Workflow.jpg): 1) we agreed that there is only one state object associated with a data object, without any notion of location in the process. This means that you can only represent a single state in the metamodel. This in itself is an issue we should address if we want to support your use case. Unless the state moves completely to the visual model, and each representation of the data object can have its own state/s. 2) I assume your process is not designed for execution. But in the case we would like to make it executable, we would need to transform/create all those state changes into assignments manually. This creates a gap between non-executable and executable processes. So as a conclusion of my evaluation: - People can do anything they like with states, so I don't see harm in allowing multiple states, all we should do is ensure that states are shown in the right order. - Diagram notation makes no mention to states, but it should since the different states are associated with the DataObjectShape class. |
| Comment by Suzette Samoojh (IBM) [ 16/Dec/08 11:49 AM ] |
|
Mariano, I don't agree with #1 in your comment above.
The State represents the state of the data in the Data Object (and not the state of the Data Object). I could easily have multiple Data Objects in the semantic model that hold the same data at different points in its lifecycle .... Data Object 1 holds "Order" when it's in state New and Data Object 2 holds "Order" when it's in state "Pending". |
| Comment by Mariano Benitez (Oracle) [ 16/Dec/08 12:42 PM ] |
|
Suzette,
The fact that there are other use cases (like your example) does not invalidate my interpretation (or my use case, or the JIRA use case, where the issue data object is the same across the process). Do you have other proposal or suggestion? I do propose to change it, but I also would like to move the state to the visual model. This proposal do not invalidate your use case, nor mine. |
| Comment by Suzette Samoojh (IBM) [ 16/Dec/08 03:52 PM ] |
|
My comment was not related to my use-case. I was simply responding to your comment #1, where the lack of a "notion of location" is raised as an issue. I don't see that location is a problem here, and I gave an example of how the current metamodel allows me to represent different states at different locations in the process flow. But maybe I'm misunderstanding what you are describing in #1.
In any case, state is not just visual-only information. Hence it needs to be in the semantic model. To address Steve's use-case of multiple States on a single DataObject at a single point in the process flow: I'd recommend we don't do anything. There are several use-cases that we could come up with, and I'm not confident we understand them all well enough to accommodate in BPMN. Hence I'd propose we leave the model as-is. Tool vendors will have to extend the DataObjectState irregardless in order to use it. So they could just as easily extend it to accommodate multiple states. The NET of all of the above is: I don't see a need for any changes. |
| Comment by Mariano Benitez (Oracle) [ 17/Dec/08 12:58 PM ] |
|
While I agree with your "action" for this issue, I would still be concerned about how to visualize the state in a diagram, we do not propose any way of displaying it. Steve's example is not compliant in this aspect.
So to expand Suzette's proposal, I would say: no need for any change in the MM, but we would need to describe how to show a state, of where... |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:46 PM ] |
|
As per the straw poll on So I will propose to close this with no change. |
| Comment by Mariano Benitez (Oracle) [ 23/Mar/10 08:31 AM ] |
|
##Proposed Resolution: Close, No Change
The FTF decided this change is not required, since it implementing another way extending state multiplicity for data objects (DataObjectRefs). See |
| Comment by Stephen White [ 01/Apr/10 11:12 AM ] |
|
Issue 15080 ( |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:48 AM ] |
|
Per the FTF call on 4/6 we agreed to take the issue off the ballot and refine the resolution description.
If there is someone who wants to defer this issue, please right a proposal. |
[BPMNFTF-445] [OMG 14769] Provide example: Basic process structure
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-310 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section 10.1.2 Raised by: Matthias Kloppmann Sub-Team responsible: "Basics" Type: Example Description of issue: Missing example for process structure Proposal: Add an example showing process structure. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 19/Feb/09 12:30 PM ] |
|
Per the 2009.02.19 examples sub-team meeting:
-- Medium priority -- The example should contain activities, events, gateways -- Combine with BPMN-316 |
| Comment by Stephen White [ 18/Mar/10 08:59 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:57 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:09 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-444] [OMG 14766] Provide example: Basic gateway examples
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-316 ##Original Info: (Severity: Significant - Nature: Enhancement) Revision of Spec: 0.5.7 Section(s) of Spec: New section 10.5.7 Examples Raised by: Matthias Kloppmann Sub-Team responsible: "Basic" Type: Example Description of issue: Missing examples for basic gateways. Proposal: Add three examples showing XOR, IOR and AND gateways. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 19/Feb/09 12:31 PM ] |
|
Per the 2009.02.19 examples sub-team meeting:
-- Medium priority -- Combine with BPMN-310 |
| Comment by Stephen White [ 18/Mar/10 08:59 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:57 PM ] |
| Update the issue resolution to say that due to the size of the specification the FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:06 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-443] [OMG 14759] Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Hagen Volzer |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-349 ##Original Info: (Severity: Significant - Nature: Enhancement) Suggested by Michael Rowley: Add Exclusive conditional behavior from activities. "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task." This was discussed on a BLOG (http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886) Proposal TBD ##Proposed Resolution: Defer The FTF agrees that this issue deserves further discussion, and could not agree on a resolution and deferred its resolution to a future RTF |
| Comments |
| Comment by Stephen White [ 21/Nov/08 05:43 PM ] |
| Assigned to Hagen for now since there are execution semantics consequences of this feature. |
| Comment by Hagen Volzer [ 22/Jan/09 09:11 AM ] |
| Seems to be related to 145, at least for subprocesses, more precisely related to the discussion there whether we want to encapsulate alternative behavior in a subprocess and how we want to show that at the interface. |
| Comment by Bruce Silver [ 24/Jan/09 06:00 PM ] |
| I don't think this is same as 145. This one uses normal semantics of subprocess completion. It is purely notational, and works the same regardless of the visual representation of the activity (unlike 145). Conditional sequence flow with the open diamond "implies" independent conditions (like OR gateway) but it "could" be used with exclusive conditions (like XOR gateway). This makes a clear distinction between the two forms of conditional sequence flow out of an activity. The downside is yet another graphic element. |
| Comment by David Marston [ 25/Jan/09 11:53 AM ] |
| Maybe you just need to say that at a certain level of formality, explicit gateways are necessary. I think we don't want a mix of exclusive and inclusive minidiamonds, which would be the next requested feature once two kinds are allowed. If you are drawing the process for human consumption, be informal and show all exit conditions as inclusive (and use an annotation to state that formal rules exist, if that would ease your guilt). If you want a model that will compile into checkboxes and/or radio buttons, draw the necessary gateways. |
| Comment by Mariano Benitez (Oracle) [ 27/Jan/09 12:37 PM ] |
|
I would really like to be able to define exclusive implicit gateways in the activity, this has been the behaviour of our product for the past 8 years and we never had a complain abou it. (This is just to express how much I like the idea, it is not an argument.) :)
Now, I agree NOT to mix exclusive and inclusive minidiamonds. What I think is that the inclusive/exclusive behaviour is an attribute of the activity. The default SF out of the activity is actually an attribute of the activity itself, so we might well add another attribute "gateway behaviour" that would be inclusive or inclusive. Actually diamonds has nothing to do with the type of gateway they are flowing out from. I prefer an activity attribute that would rule for all conditional SF out of the activity. |
| Comment by Hagen Volzer [ 28/Jan/09 02:30 AM ] |
| Is there any reason why we would like to have this feature only on the output side but not on the input side? |
| Comment by Stephen White [ 28/Jan/09 05:17 PM ] |
|
I understand Mariano's point of view on this issue. A few tool vendors involved in V1.0 had similar features and so the mini diamond was added. I would have preferred that ALL Sequence Flow control be handled by Gateways. Having both Gateways and mini diamonds is too much notation, in my opinion. BPMN is already dinged by people who say that it is too complex. I would not suggest that we remove the mini-diamonds, since they are legacy, but I would prefer that we don't add any more notation to V2.0 than we have to.
I would recommend that we defer this issue. |
| Comment by Mariano Benitez (Oracle) [ 30/Jan/09 08:21 AM ] |
|
I think multiple sequence flows in/out of activities is a reasonable shortcut that most of our customers use, it makes the visual diagram cleaner.
Actually, in the case of multiple incoming sequence flows, it behaves like an exclusive gateway, different from the outgoing side. (see section 13.2.1) There is no reason why people would not want inclusive gateway semantics on the incoming side too. I don't think it is too much of a change to add 2 attributes that describe the incoming and outgoing behaviour, and it would make the semantics more consistent and flexible for users. So, I would recommend we open this issue with the proposal I just made. |
| Comment by Stephen White [ 25/Sep/09 03:10 PM ] |
| Summary updated to match Beta 1 spec sections |
| Comment by Stephen White [ 22/Mar/10 01:49 PM ] |
| proposalScheduledForBallot11 |
| Comment by Hagen Volzer [ 25/Mar/10 03:28 AM ] |
|
##Proposed Resolution: Defer
There is not enough time in the FTF to reach agreement for the necessary changes for this issue |
[BPMNFTF-442] [OMG 14760] Data flow in/out of events
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-347 ##Original Info: (Severity: Significant - Nature: Revision) Data flow should work with events, rather than just send and receive tasks and activities. Modelers sh9uldn't need to change the model so much just to add data flow. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:52 PM ] |
| Events contain data associations. So, data can flow into and out of them. Not sure I understand the issue. |
| Comment by Ivana Trickovic [ 10/Mar/10 04:45 AM ] |
|
As per March F2F Meeting:
- Yes, this is already in the specification as Suzette indicated above. - Close (no problem) with no changes to the specification. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:08 PM ] |
|
##Proposed Resolution: Closed, No Change
This is not a problem with the specification, so we close with no change |
[BPMNFTF-441] [OMG 14756] Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-361 ##Original Info: (Severity: Critical - Nature: Revision) Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content. This section should match a parallel section in Chapter 10 (Process). |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 07:56 AM ] |
|
As per March F2F Meeting:
- Additional text could be added to the specification, but it will describe existing capabilities - Therefore decided to lower the priority to minor |
| Comment by Stephen White [ 19/Mar/10 06:37 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:47 PM ] |
| Update the issue resolution to say that this editorial issue is a request for a new section that would include no new normative text. This is why the FTF agreed to defer this issue. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:01 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-440] [OMG 14754] Pools multiplicity
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Bruce Silver | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: Bruce Silver Associates (Bruce Silver, bruce@brsilver.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-372 ##Original Info: (Severity: Significant - Nature: Revision) Table 9-1 says a diagram containing pools, i.e. Collaboration, must contain 2 or more. Then is says "Note that the multiplicity of the pools model association is an open issue and may be changed in a later revision of the specification," but it is unclear whether this means the minimum of 2 pools in a diagram or relates to the MI marker on pools. If the former, I think the minimum should be 1 and it should not wait until a later revision of the sepcification. The reasons are 1) backward compatibility with BPMN 1.1, in which all BPDs were assumed to have at least one pool, whether boundary visible or not; and 2) ability for modelers to create diagrams with just one pool, labeled with name of the process... and be able to create schema-valid xml from it. Also... following fig 9-4 it says " ...the Activities that represent the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" Activities and are not required to be surrounded by the boundary of their Pool...". This is only true if all the activities are part of a single process (orchestration). I think better to say, "...a single process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not required to be surrounded by the boundary of its Pool...". ##Proposed Resolution: Fixed The metamodel allows for Collaborations to have zero (0) or more Pools. Thus, it is possible to create a Collaboration with just one Pool. The statement that a Collaboration contains two (2) Pools is inaccurate and will be fixed. The statement about multiplicity of Pools being an open issue was removed from the specification prior to the completion of the Beta version. Section 9.2, page 116 (146 pdf), first paragraph below Figure 9.4: (a) Change first sentence to: "A Collaboration can contain at two (2) or more Pools (i.e., Participants)." (b) Change second sentence to: "However, a Process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not required to be surrounded by the boundary of the Pool, while the other Pools in the Diagram MUST have their boundary." |
| Comments |
| Comment by Ivana Trickovic [ 21/Jan/09 07:01 AM ] |
| Bruce's comment: Second part is editorial issue. First part is MM issue. |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:51 PM ] |
|
Regarding 2-ability to create diagrams with one pool and create schema-valid xml. Given our statements on interchange of partially defined models (section 16.1), it is already possible to interchange such an xml. And certainly a tool should allow a user to create such 'partial' model.
The real question is: Is a collaboration of one a valid and complete collaboration. Intuitively it's not. |
| Comment by Stephen White [ 19/Mar/10 06:43 PM ] |
| proposalScheduledForBallot11 |
| Comment by Pete Rivett [ 28/Apr/10 05:38 PM ] |
|
In the resolutiuon the first new sentence is
1) ungrammatical "contain at two or more pools" 2) does not address the problem of a minimum of 2 pools being required the second new sentence: 3) does not draw a distinction between the notation (with Pools) and the model (with Particpants) - specifically, even though there may not be a Pool depicted, is it still a requirement that a Collaboration has at least two participants? 4) perpetuates the confusion of the original with phrases like 'the modeler's organization' when this is not represented int he model |
| Comment by Stephen White [ 03/May/10 01:14 PM ] |
|
---------------- Conference call on 2010-05-03 --------------------
Responses to Pete Rivett's previous comment: 1) ungrammatical "contain at two or more pools" ---was fixed editorially. 2) does not address the problem of a minimum of 2 pools being required the second new sentence: The schema and metamodel do not require a minimum of 2 Pools in a Collaboration. There were two other statements in the spec (Section 7.1.1 and Section 9.1) that indicated this minimum. ---These will be updated editorially per this resolution. 3) does not draw a distinction between the notation (with Pools) and the model (with Particpants) - specifically, even though there may not be a Pool depicted, is it still a requirement that a Collaboration has at least two participants? ---There is some language in Section 9.2 to indicate that the Pool is the representation of a Participant in a Collaboration. However, we agree that further clarification (editorially). Thus, "A Pool represents a Participant in a Collaboration" will be changed to "A Pool is the graphical representation of a Participant in a Collaboration" 4) perpetuates the confusion of the original with phrases like 'the modeler's organization' when this is not represented in the model ---We still do not fully understand this aspect of the issue (i.e., the confusion that is perpetuated). We suggest that another issue be raised so that we can address this properly in the RTF. |
[BPMNFTF-439] [OMG 14761] Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | WS-BPEL Mapping |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-344 ##Original Info: (Severity: Significant - Nature: Revision) Revision of Spec: Beta 1 Section(s) of Spec: Raised by: Matthias Kloppmann Sub-Team responsible: BPEL mapping Type: Technical Description of issue: 1. The spec misses the mapping for intermediate message send events 2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant. Proposal: 1. Include that mapping into spec (see Visio) 2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation. |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:26 AM ] |
| Suggest to defer to RTF, not critical, does not prevent implementation of spec. |
| Comment by Ivana Trickovic [ 04/Apr/10 11:51 PM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. (E.g. see the comment from Matthias.) |
| Comment by Ivana Trickovic [ 06/Apr/10 03:02 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-438] [OMG 14755] Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-362 ##Original Info: (Severity: Critical - Nature: Revision) Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content. This section should match a parallel section in Chapter 11 (Choreography). |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 07:56 AM ] |
|
As per March F2F Meeting:
- Additional text could be added to the specification, but it will describe existing capabilities - Therefore decided to lower the priority to minor |
| Comment by Stephen White [ 19/Mar/10 06:44 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:47 PM ] |
| Update the issue resolution to say that this editorial issue is a request for a new section that would include no new normative text. This is why the FTF agreed to defer this issue. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:00 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-437] [OMG 14757] [Chroeography] Complete section 11.4: Events
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Martin Chapman | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Oracle (Martin Chapman, martin.chapman@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-360 ##Original Info: (Severity: Critical - Nature: Revision) Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events. Each sub-section may require more text, review and some example and pictures. ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Ivana Trickovic [ 12/Dec/08 06:37 AM ] |
| Issue assigned to Steve/the choreography team. |
| Comment by Ivana Trickovic [ 15/Mar/10 07:51 AM ] |
|
As per March F2F Meeting:
- Leave the issue, as content is missing. |
| Comment by Stephen White [ 19/Mar/10 06:45 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:49 PM ] |
| Move on ballot #11 as specification text is missing. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-436] [OMG 14726] Beta 1: Set the name attribute of DataInputs and DataOutputs to optional
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-481 ##Original Info: (Severity: Minor - Nature: Enhancement) Names are not require for all DataInputs and DataOutputs. Names would be used mainly for the ones that are shown graphically on the diagram. ---------------------- Proposed Resolution -------- 2010-04-02 --------------------- ##Proposed Resolution: Fixed Change the name attribute for both DataInput and DataOutput to be optional. (a) Table 10.53 DataInput attributes and model associations, name attribute row, first column: change "string" to "string [0..1] (b) Table 10.54 DataOutput attributes and model associations, name attribute row, first column: change "string" to "string [0..1] (c) Table 10.65 DataInput XML schema: Change "attribute name="name" type="xsd:string"" to "attribute name="name" type="xsd:string" use="optional"" (c) Table 10.70 DataOutput XML schema: Change "attribute name="name" type="xsd:string"" to "attribute name="name" type="xsd:string" use="optional"" |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 12:41 PM ] |
|
They are already optional in the XSD. The spec text doesn't appear to indicate they are required.
[Also note that process/sub-process-level DataInputs and DataOutputs may be visualized] |
| Comment by Stephen White [ 22/Mar/10 01:23 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 02/Apr/10 04:38 PM ] |
| New Proposed Resolution |
[BPMNFTF-435] [OMG 14729] Add an example of Mutlple Start Events on the Boundary of a Sub-Process
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-475 ##Original Info: (Severity: Significant - Nature: Enhancement) Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section. Section 10.2.5, Beta 1 spec |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:25 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:40 PM ] |
| Update the issue resolution to say that due to the size of the specification that FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 02:51 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-434] [OMG 14741] Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-421 ##Original Info: (Severity: Significant - Nature: Enhancement) The background text for the description of Collaboration is rather thin. Add more description and a figure or two. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:26 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:42 PM ] |
| Update the issue resolution to say that this is not an implementation issue so the proposal is to defer it, instead of just saying that the FTF was not able to allocate time. |
| Comment by Ivana Trickovic [ 06/Apr/10 02:54 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-433] [OMG 14734] Lanes should be described in Process section
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-455 ##Original Info: (Severity: Critical - Nature: Revision) Lanes are pat of process modeling and should be described in the Process section. They are currently documented in the Collaboration chapter, which happens to use process models. -------------------------- Proposal on 2009-12-10 ---------------------------------- ##Proposed Resolution: Closed; No Change This issue was mistakenly added to the list. The issue had already been fixed. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 14/Apr/09 10:30 AM ] |
| The resolution to this issue was applied in V0.9.9.5 |
| Comment by Stephen White [ 10/Dec/09 04:57 PM ] |
|
-------------------------- Proposal on 2009-12-10 ----------------------------------
This issue was mistakenly added to the list. The issue had already been fixed. ----------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-432] [OMG 14742] Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-416 ##Original Info: (Severity: Significant - Nature: Revision) In BPMN 1.1, there were Reference Tasks and Sub-Processes, which provided a type of within Diagram reusability--as opoposed to Global Tasks reused across diagrams. Any feature that is in 1.1, but not 2.0 should have some documentation as to why it is not there. This issue could be used to re-introduce the elements or to document why they were excluded in this version. -----------Proposal----------------Apr 5, 2010--------------------------- ##Proposed Resolution: Fixed In Changes annex (Annex A) add: "Reference Tasks are removed. These provided reusability within a single diagram, as compared to GlobalTasks, which are resuable across multiple diagrams. GlobalTasks can be used instead of Reference Tasks, to simplify the language and implementations." |
| Comments |
| Comment by Stephen White [ 03/Feb/09 05:39 PM ] |
| This could be potential resolved by modifying the Call Activity so that it can also call activities within the same diagram (which was what the Reference Task and Reference Sub-Process did). |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:45 PM ] |
| Or it could be resolved by having a Global Task, with Call Activities calling it. A tool can then control access to that Global Task ... i.e. only allow a user to use it within a single process. |
| Comment by Suzette Samoojh (IBM) [ 11/Feb/10 04:22 PM ] |
| Recommend closing with no change. The capability is there via Call Activities. The only differentiator is scope of re-use (reuse in different processes vs reuse within a single process), but that is something that a tool can easily control. There is no real functional loss. |
| Comment by Stephen White [ 22/Mar/10 07:34 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 24/Mar/10 03:48 PM ] |
|
------------ Conference Call on 2010-03-24 -------------------------
Agreed to Close; No Change. Reassign to Conrad An explanation will be added as to how the user is better served with current capabilities The explanation should be put in the appendix of changes between V1.2 and V2.0, being handle by Issue 14788 (JIRA 480) |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 02:59 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Fixed In Changes annex add: "Reference Tasks are removed. These provided reusability within a single diagram, as compared to GlobalTasks, which are resuable across multiple diagrams. GlobalTasks can be used instead of Reference Tasks, to simplify the language and implementations." |
[BPMNFTF-431] [OMG 14743] Relationship navigation (both in MM and XSD)
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Unassigned |
| Resolution: | No Action | Votes: | 1 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-413 ##Original Info: (Severity: Critical - Nature: Revision) Beta 1, Section 8.4 Currently the MM contains a bidirectional relationship between Interface and ServiceRef. This is also represented in the XSD, where the Interface complexType has an element that references a ServiceReference, and the ServiceReference complexType has an element that references an Interface. In the Samples meeting, it was raised that the Interface->ServiceReference relationship was not needed in the XSD. This discussion resulted in several outstanding questions: - If it doesn't belong in the XSD, should it be in the MM? - Tool vendors would find this convenient to have. But is that an implementation issue? - This likely isn't the only case. Need to have a broader discussion. - What is the purpose of the MM? How are we positioning it? - If the MM is for portability, then should the arguments used against the XSD also apply to the MM? -----Proposal---------------- 02/16/2010 ------------------------- ##Proposed Resolution: Closed, No Change - This issue has been carried over from the BPMN 2.0 submission team - Ongoing implementation projects do not indicate this is an issue. Close with no changes to the specification (as it is not a problem) |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 29/Jan/09 03:11 PM ] |
|
IMO, the meta-model defines the data entities and their relationships, as the base for the "BPMN 2.0 language" the spec defines, in two dialects, XMI and XML. Instances of this language are used as a means to transport the semantic information between vendors' tools (and runtimes).
How those language instances are used beyond transporting them between tools and runtimes is beyond the scope of the specification; in particular how a particular vendor's implementation accesses them, which access paths are used etc. As such, the meta-model shouldn't mandate whether links are navigable or not, just express relationships. The same holds for the XSD representation. Pragmatically, IMO this means that any 1 to n relationship should be navigable only from the "n side" to the "1 side", with the additional benefit that this results in the "expected" XSD mapping. (This occurs indeed several times -- another example is the relationship between activities and sequence flows. While it's natural that a sequence flow identifies its single source and target, there is no need to also instantiate the redundant information per activity which incoming and outgoing sequence flows it has -- which the current XSD requires.) |
| Comment by Suzette Samoojh (IBM) [ 29/Jan/09 04:43 PM ] |
|
I agree with Matthias on the first two paragraphs.
I tend to agree with the third (and fourth) paragraphs, but would prefer to do a sweep through the MM, see if there are any exceptions, before we apply this as a global design principle. |
| Comment by Ivana Trickovic [ 30/Jan/09 04:35 AM ] |
| As per 1/29 BPMN Examples meeting: The issues moved to "open" and assigned to Suzette. |
| Comment by David Marston [ 01/Feb/09 09:25 PM ] |
| I tend to disagree with Matthias' fourth paragraph. If he is saying "there is no need" in the sense that the other direction can be calculated before any structural interpretation that is node-centric, then I would concede that point with some qualifiers. In the type of pragmatic transformation I do, I generally take a node-centric approach. I "need" the references from the node-centric point of view. See BPMN-410 for a longer treatise on the relation between gateways and sequence flows. |
| Comment by Ralf Mueller [ 01/Feb/09 09:45 PM ] |
| I agree with Matthias here but would love to see more examples and one round through the MM before we modify the XSD's, maybe on a case-by-case basis. |
| Comment by Suzette Samoojh (IBM) [ 03/Feb/09 02:02 PM ] |
|
In the Feb 2nd meeting, the group agreed to the following:
- The ServiceReference->Interface should be removed from the XSD. In the MM, it would be marked as 'derived'. - This approach could likely be applied to other similar cases. - To Do [for Suzette]: Do an initial pass over the MM and identify similar cases. Work with the subteams to determine if the 'derived' solution applies to their individual cases. |
| Comment by Ivana Trickovic [ 07/Apr/09 04:01 AM ] |
| As per 4/6 BPMN 2.0 meeting: Defer BPMN-413. |
| Comment by Stephen White [ 25/Sep/09 04:04 PM ] |
| Updated section to match Beta 1 spec |
| Comment by Ivana Trickovic [ 09/Mar/10 08:04 AM ] |
|
As per March F2F Meeting:
- This issue has been carried over from the BPMN 2.0 submission team - Ongoing implementation projects do not indicate this is an issue. Therefore this issue is not critical. - Proposal is to close with no changes to the specification (as it is not a problem) |
[BPMNFTF-430] [OMG 14728] Data Assignment 'from' and 'to' should be formal expressions
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Oracle (Ralf Müller, ralf.mueller@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-477 ##Original Info: (Severity: Significant - Nature: Revision) In Data Assignment, the 'from' and 'to' attributes are Object. The Assignment class should be modified as following 1. Remove 'language' attribute 2. Data Type of 'from' and 'to' is FormalExpression Apart from that, the attribute 'evaluatesToTypeRef' in FormalExpression class should be optional ##Proposed Resolution: Duplicate This issue has the same resolution as OMG 14701 ( |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:59 PM ] |
| proposalScheduledForBallot11 |
| Comment by Suzette Samoojh (IBM) [ 16/Mar/10 10:18 AM ] |
|
See |
[BPMNFTF-429] [OMG 14735] Data Association should be specialized from Association
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-445 ##Original Info: (Severity: Significant - Nature: Revision) Association has a source and target of BaseElement which should inherit to DataAssociation, instead of being defined again on Data Association. ------------- New Proposed Resolution ----- 2010-02-03 ------------- ##Proposed Resolution: Close, No Change Close, no change. The issue requests a metamodel simplification that would be confusing and would not provide sufficient benefits. ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 03/Feb/10 04:37 PM ] |
|
-------------------- Discussion during Converence call on 2010-02-03 -----------------------
Association and Data Association are semantically different elements (even though they look the same) We made a conscious decision to separate Is this important now? The DataAssociation connects ItemAware elements and Association connects BaseElements Conceptually, the two are different and the simplification requested by the issue does not provide enough value. Action: Close: no change |
| Comment by Stephen White [ 03/Feb/10 04:39 PM ] |
|
------------- New Proposed Resolution ----- 2010-02-03 -------------
Close, no change. The issue requests a metamodel simplification that would be confusing and would not provide sufficient benefits. ---------------------------------------------------------------------------------------- |
[BPMNFTF-428] [OMG 14730] Initializing and updating properties is not straight-forward
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-471 ##Original Info: (Severity: Minor - Nature: Revision) From examples meeting on 2009.03.26: When creating the looping example for Proposal: (1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element. (2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef. ##Proposed Resolution: Defer This issue can be handled by an RTF. |
| Comments |
| Comment by Ivana Trickovic [ 07/Apr/09 04:00 AM ] |
| As per 4/6 BPMN 2.0 meeting: Defer BPMN-471. |
[BPMNFTF-427] [OMG 14727] XSD: Data Association sourceRef and targetRef should be of type QName
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Ralf Müller, ralf.mueller@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-478 ##Original Info: (Severity: Minor - Nature: Revision) Consider a Call Activity that invokes another Process: <callActivity id="CallActivity" calledElement="tns:CalledProcessNotServiceEnabled"> <dataInputAssociation> <sourceRef>MyOrder</sourceRef> <targetRef>Order</targetRef> </dataInputAssociation> <dataOutputAssociation> <sourceRef>Result</sourceRef> <targetRef>MyResult</targetRef> </dataOutputAssociation> </callActivity> In above sample, the targetRef of the data input association refers to a DataInput object of process 'CalledProcessNotServiceEnabled' and the sourceRef of the data output association refers to a DataOutput object of the called process. The proposal is to modify the XML-Schema type of sourceRef and targetRef from xsd:IDREF to xsd:QName to allow references to processes and global tasks data input/output that appear in potentially separate BPMN definitions. ##Proposed Resolution: Fixed The XML-Schema and the tables 10.66 and 10.71 were not consistent. The proper definition is that sourceRef and targetRef are xsd:IDREF. Technically this is a close, no change but we are fixing the inconsistency here. The XML-Schema for sourceRef and targetRef to be changed from xsd:QName to xsd:IDREF. Tables 10.66, 10.71 are correct. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 15/Mar/10 12:31 PM ] |
|
Isn't this the opposite of what was decided in the F2F?
I thought the decision was that the CallActivity data inputs and data outputs would be referenced by the data associations. Not the CallableElement data inputs and data outputs. Hence there is no need for QNames. IDREFs would suffice. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 12:41 PM ] |
|
Suzette, if the IDREFs would be ok, we need to change the current XSD schema, since now it is using QNames. Either way we need to fix them. I am ok with IDREFs, so I can update the resolution to reflect the schema change.
|
| Comment by Suzette Samoojh (IBM) [ 15/Mar/10 12:49 PM ] |
|
Yes, you're right. The current schema uses QNames. [Not sure I understand the 'Fixed' resolution then, if no schema change is needed].
But I wouldn't say we have to change the XSD. QName doesn't reflect the intent, but would not break interchange. So the current schema is still usable. In any case, I was more reacting to your description on how to use the XSD. The data input of the called process should not appear in the XML. Rather it should be the data input of the call activity. I propose we close with no change. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:05 PM ] |
|
The XSD and the 2 tables I mentioned are out of sync (XSD used QNames, tables uses IDREFs). Whatever we fix, I'm ok.
This inconsistency is found on the Beta, so I suggest we close as a fix, since there will be a change to make them consistent. |
| Comment by Suzette Samoojh (IBM) [ 15/Mar/10 03:35 PM ] |
| Okay, I see. Given that, I'd suggest we change the XSD then. Make it IDREFs. No change to the spec tables. |
[BPMNFTF-426] [OMG 14732] Global Task should have performer, Call Activity should have capability to overwrite performer
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Oracle (Ralf Müller, ralf.mueller@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-467 ##Original Info: (Severity: Significant - Nature: Revision) A Global Task should have a (default) performer. Right now that is missing in the meta model. A Call Activity then should have the capability to overwrite the performer of the global task it is calling. Example: (Global User Task) <globalUserTask id="approveOrder" name="Approve Order" implementation="humanTaskWebService"> <documentation> Given an order and customer data, approve or reject the order. </documentation> <ioSpecification> <dataInput id="approveOrder-input1" structureDefinitionRef="tns:customerStructure" optional="false"/> <dataInput id="approveOrder-input2" structureDefinitionRef="tns:orderStructure" optional="false"/> <dataOutput id="approveOrder-output" structureDefinitionRef="tns:resultStructure"/> <inputSet id="approveOrder-is"> <dataInputRefs>aproveOrder-input1</dataInputRefs> <dataInputRefs>aproveOrder-input2</dataInputRefs> <outputSetRefs>approveOrder-os</outputSetRefs> </inputSet> <outputSet id="approveOrder-os"> <dataOutputRefs>aproveOrder-output</dataOutputRefs> <inputSetRefs>approveOrder-is</inputSetRefs> </outputSet> </ioSpecification> <performer name="Regional Manager" id="regionalManager"/> <potentialOwner> <peopleAssignmentPeopleGroup definition="regionalManagers"> <parameter parameter="city"> <formalExpression>getDataInput('approveOrder-input1')/address/city</formalExpression> </parameter> <parameter parameter="country"> <formalExpression>getDataInput('approveOrder-input1')/address/country</formalExpression> </parameter> </peopleAssignmentPeopleGroup> </potentialOwner> <rendering> <documentation>HTML Rendering</documentation> <html xmlns="http://w3c.org/html"> <h1>Approve Order</h1> </html> </rendering> </globalUserTask> ##Proposed Resolution: Fixed (a) Change the MM relationship in GlobalTask from Performer to ResourceRole (ex ActivityResource, see issue 408) and rename the relationship from "performers" to "resources". 1. Change Figure 10.42 to reflect this change 2. Change the sentence below Figure 10.42 to the following content: "The Global Task inherits the attributes and model associations of Callable Element (see Table 8.30). Table 10.XX presents the additional model associations of the GlobalTask:" 3. Create a new table: resources: ResourceRole [0..*] => Defines the resource that will perform or will be responsible for the GlobalTask. In the case where the CallableElement that references this GlobalTask defines its own resources, they will override the ones defined here. (b) Add the following sentence to section 10.2.6 CallAcivity: "When the CallActivity defines one or more ResourceRole elements, the elements defined by the CallableElement are ignored and the elements defined in the CallActivity are used instead." (c) Change Table 10.131 - GlobalTask XML schema: replace "performer" with "resource". |
| Comments |
| Comment by Ivana Trickovic [ 07/Apr/09 04:03 AM ] |
| As per 4/6 BPMN 2.0 meeting: Defer BPMN-467 |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:41 PM ] |
| A 'performer' attribute was previously added to Global Task. So the remaining issue is the ability to override. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
| Comment by Mariano Benitez (Oracle) [ 23/Mar/10 03:43 PM ] |
|
We need to add a description in section 10.2.7 describing the Performer (ActivityResource) attribute and how it is overriden in the CallActivity.
Open issues: 1) Shouldn't we allow ActivityResource in a Global Task as opposed to just Performer? This way is simetric with Activity. 2) How do I identify which performer do I override? There maybe multiple performers for an activity, and they do not have an identifier. Do we reference them by ID? |
| Comment by Stephen White [ 24/Mar/10 08:00 PM ] |
|
------------- Conference Call on 2010-03-24 ------------------------
We agreed that the Global Task should contain Activity Resource instead of Performer ActivityResource will be changed to ResourceRole for Issue 408 A sentence should be added to the text for Call Activity that the ResourceRole owned by the CallActivity would override a ResourceRole owned by whatever is called. |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 08:13 PM ] |
|
You have not answered my question: there maybe multiple activity resources (resource role) in any activity, so how do I discriminate which one is overriden?
You can choose to override all or nothing, so if there is at least one activity resource in the call activity, it overrides all activity resources in the global task. |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 01:25 PM ] |
| New Proposed Resolution |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:10 AM ] |
| Updated to reflect comments from Pete Rivett, clarifying the semantics to override resources. |
[BPMNFTF-425] [OMG 14738] Notation for alternaitve data input/output sets
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-433 ##Original Info: (Severity: Critical - Nature: Revision) Notation for data input/output sets is missing. I/O sets have a similar execution effect as decision and merge gateways, so it seems like they should be visible. |
| Comments |
| Comment by Stephen White [ 13/Mar/09 01:50 PM ] |
|
The decision on this for BPMN 1.X was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider.
But, in general, in probably should be deferred for now. |
| Comment by Ivana Trickovic [ 09/Mar/10 08:07 AM ] |
|
As per March F2F Meeting:
- This is not an implementation issue so agreed to lower the priority to minor |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 10:40 AM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
[BPMNFTF-424] [OMG 14733] [XSD] Documentation and ScriptTask (and probably expressions) should be stored as CData elements and not String attributes
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Won't Fix | Votes: | 0 |
| File Attachments: |
testXMLFor_BPMNFTF-424.xml
testXMLFor_BPMNFTF-424b.xml
|
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-459 ##Original Info: (Severity: Significant - Nature: Revision) Documentation and the scripts are formatted text, we should keep the format (spaces, tabs) that the user defined. Storing formatted text as string attributes makes it impossible to do so, since it turns the attributes quite big and looses the format. It would be better if we store any formatted text as a CDATA element, so we can easily keep the format. Proposal: change the XSD for documentation, script task and formal expressions to use a CDATA element instead of a string attribute. ##Proposed Resolution: Close; No Change The issue was opened against an older (pre-Beta) version of the BPMN XSD. The problems described no longer occur. Examples of how text can store any formatted text as a CDATA element can be seen here: http://www.osoa.org/jira/secure/attachment/10684/testXMLFor_BPMNFTF-424b.xml |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 16/Mar/09 11:23 AM ] |
|
In the current XSD, Documentation is a complexType that accepts mixed content. It's not just a String attribute.
<xsd:complexType name="tDocumentation" mixed="true"> <xsd:sequence> <xsd:any namespace="##any" processContents="lax" minOccurs="0"/> </xsd:sequence> </xsd:complexType> I've tested this with documentation text that uses HTML tags, and it validates correctly. Can you provide an example that does not validate? A similar approach is used for the text in TextAnnotations and also for Expressions. As above, can you provide examples where the current schema will not work? You are right about ScriptTasks. Currently, the script is just a simple String. And so it needs to change. |
| Comment by Suzette Samoojh (IBM) [ 17/Mar/09 04:28 PM ] |
|
The ScriptTask has been updated in the XSD published today. It now allows for a script with mixed content.
|
| Comment by David Marston [ 20/Mar/09 08:13 PM ] |
| Regarding expressions: note that XPath has been designed to be stored in a string attribute. |
| Comment by Mariano Benitez (Oracle) [ 20/Apr/09 09:47 AM ] |
|
Suzette, this looks like it is fixed already (checked in 0.9.9.5).
Should we close it as applied? |
| Comment by Suzette Samoojh (IBM) [ 20/Apr/09 11:43 AM ] |
|
Mariano, I didn't touch the Documentation or FormalExpression elements in the XSD. They are as they previously were.
I did fix the Script task. [See my comments on March 16 & 17 above]. So, we can mark as 'applied' as long as you are satisfied with the approach in 0.9.9.5, and don't believe there are still changes needed to the Documentation or FormalExpression element.s |
| Comment by Mariano Benitez (Oracle) [ 24/Apr/09 01:50 PM ] |
|
Currently in spec text the formal expression is the inner text of the element. This does not support XML tags inside the expression.
We should follow the same pattern as with Script Task (e.g. add an inner "expression" element). We should also change the spec text to reflect the inner elements. In the text for ScriptTask (table 10-12) the "script" is a string, not an element. Regarding documentation, now that it is an element, I think we are fine. So: summarize: 1) In Table 8-6 - Documentation Attributes - There is no such attribute as "text". We should remove the attribute and at least make a comment about the way to store it. 2) Table 10-12 - Script Task attributes. The script should be an object, not a string. (or whatever we define for 1) 3) We should include an inner element for the "expression" in FormalExpression, same way as 1) and 2) and change the text accordingly. If you want I can work a MM and text proposal. Regards, |
| Comment by Mariano Benitez (Oracle) [ 05/May/09 01:16 PM ] |
|
Making a very quick review of this issue I see it is not just minor change. It requires fixes in MM, XSD and text.
I can make a proposal for a MM resolution, which would drive the text and XSD changes. My proposal is to: 1) defer the issue 2) assign it to me 3) make a MM proposal with detail description. Agree on the proposal and them create a text and XSD proposal. Suzette, what do you think? |
| Comment by Suzette Samoojh (IBM) [ 06/May/09 05:24 PM ] |
|
Please feel free to work on a proposal. Thanks for the offer.
But I'd recommend defering to the FTF. |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:04 PM ] |
| proposalScheduledForBallot11 |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 01:09 PM ] |
|
I ran some tests against the current XSD, and encountered no issues. See http://www.osoa.org/jira/secure/attachment/10669/testXMLFor_BPMNFTF-424.xml
So, unless there is a scenario I didn't cover and which is still broken, will assume the issues have already been addressed. -------------------------------------------------------------------------------------- Proposed resolution: Close with no change The issue was opened against an older (pre-Beta) version of the BPMN XSD. The problems described no longer occur. |
| Comment by Mariano Benitez (Oracle) [ 06/Apr/10 10:43 AM ] |
|
Suzette,
Think of these simple cases: 1) <textAnnotation><text>Testing with some <b>inline BPMN inside my text annotationn</b> content: <process>blah</process></text></textAnnotation> 2) <textAnnotation><text>Or even some invalid XML, this would break the file. e.g</process> <!-- yep, this is possible too <a></bc></text></textAnnotation> We should protect against any of this possible cases, altough not common on purpose, they might surely happen, well, they can probably happen if people paste XML snippets or BPMN examples inside text. |
| Comment by Suzette Samoojh (IBM) [ 07/Apr/10 04:46 PM ] |
|
Both of those can be addressed by using CDATA. Note that CDATA only appears in XML. You can't type something as CDATA in an XSD (to my knowledge) unless you use proprietary extensions.
Using your two examples, they would be done like this: <textAnnotation> <text> <![CDATA[Testing with some <b>inline BPMN inside my text annotationn</b> content: <process>blah</process>]]> </text> </textAnnotation> <textAnnotation> <text> <![CDATA[Or even some invalid XML, this would break the file. e.g</process> <!-- yep, this is possible too <a></bc>]]> </text> </textAnnotation> I've attached a new version of the xml, including these two cases. So, still propose to Close with no change. |
| Comment by Mariano Benitez (Oracle) [ 07/Apr/10 05:14 PM ] |
|
so what you just mentioned is that inside the <text> element you can use CDATA to include any content basically, then I'm ok to close with no change but probably including the snippets you just mentioned to prove how to do it.
Thanks, |
[BPMNFTF-423] [OMG 14731] Editorial: Rename FlowElement::categoryValue to ::categoryValueRef
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
MM_Group.jpg
|
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-470 ##Original Info: (Severity: Minor - Nature: Revision) As per discussion in examples working session on 2009.03.26 ------------------ PROPOSAL -------------------------01/11/2010---------------------------- ##Proposed Resolution: Fixed (a) Replace Figure 8.15. See the change is circled in red in http://www.osoa.org/jira/secure/attachment/10584/MM_Group.jpg (b) Replace Figure 8.23 to include the CategoryValue element and the association to Flow Element (c) Update Table 8.45. Add attribute "categoryValueRef" with description "A reference to the category values that are associated with this flow element". (d) Update the XSD snippet (Table 8.66) to rename "categoryValue" to "categoryValueRef". No change needed to the actual XSD. It already contains the correct name. ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 01:54 PM ] |
| Picture showing updates to the LinkEventDefinition metamodel |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 02:29 PM ] |
|
Oops. Wrong issue.
Please ignore the jpg attached. |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 05:24 PM ] |
|
------------------ PROPOSAL -------------------------01/11/2010----------------------------
Replace Figure 8.15. See MM_Group.jpg (the change is circled in red). Update Table 8.45. Add attribute "categoryValueRef" with description "A reference to the category values that are associated with this flow element". Update the XSD snippet (Table 8.66) to rename "categoryValue" to "categoryValueRef". No change needed to the actual XSD. It already contains the correct name. |
| Comment by Stephen White [ 12/Jan/10 03:46 PM ] |
| New Proposed Resolution: Fixed |
| Comment by Stephen White [ 12/Jan/10 09:20 PM ] |
| The LinkEventDefinition metamodel has been deleted. The MM_Group.jpg is the one to look at for the resolution. |
[BPMNFTF-422] [OMG 14739] Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Ivana Trickovic |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-429 ##Original Info: (Severity: Significant - Nature: Revision) Since all activities have performers and priorities. it makes sense to be able to use the actual performer or priority of any activity in the definition of any other activity. E.g., the performer of this activity cannot be the same as that activity. Performers can do the work as in User Tasks, or just be stakeholders or authorizers, etc. for any activity (including sub-processes). Right now only User Activities have these instance attributes. Moving the attributes to the Activity level would allow other activities this capability. ##Proposed Resolution: Close; No Change These instance attributes are defined for User Tasks only, as they are needed for different human interaction scenarios. For other task types, e.g. Receive Task, Send Task, Service Task, Business Rule Task the value of having these instance attributes is not clear. E.g. It is not clear what would be the Actual Owner of a Receive Task or a Send Task. The proposal is to close this issue with no changes to the specification. |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:35 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 26/Mar/10 08:52 AM ] |
|
------------------- Proposal ------------ 2010-03-26 -------------------------------------------------
##Proposed Resolution: Close; No Change These instance attributes are defined for User Tasks only, as they are needed for different human interaction scenarios. For other task types, e.g. Receive Task, Send Task, Service Task, Business Rule Task the value of having these instance attributes is not clear. E.g. It is not clear what would be the Actual Owner of a Receive Task or a Send Task. The proposal is to close this issue with no changes to the specification. |
| Comment by Ivana Trickovic [ 26/Mar/10 08:52 AM ] |
| New Proposed Resolution |
[BPMNFTF-421] [OMG 14736] Add business-level presentation attributes to user task: subject and description.
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-441 ##Original Info: (Severity: Significant - Nature: Revision) From the human interactions example: Need to add business-level presentation attributes known from BPEL4People, namely subject and description. This should include the ability to specify presentation parameters - needs discussion. Without these, the user task capability is not rich enough for serious direct execution, but will always require mapping to and enrichment in BPEL4People. ##Proposed Resolution: Fixed Rather than copying the various BPEL4People elements to the BPMN spec, we should modify the BPMN spec as follows: Text in section "10.2.4 Human Interactions" Current: The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the User Task. New: The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the User Task. If implementations extend these attributes (e.g., to introduce subjects or descriptions with presentation parameters), they SHOULD use attributes defined by the OASIS WS-HumanTask specification. |
| Comments |
| Comment by Stephen White [ 24/Mar/10 03:26 PM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:47 AM ] |
|
Proposal:
Rather than copying the various BPEL4People elements to the BPMN spec, we should modify the BPMN spec as follows: ---------------------------------- Text in section "10.2.4 Human Interactions" ---------------------------------- Current: The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the User Task. New: The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the User Task. If implementations extend these attributes (e.g., to introduce subjects or descriptions with presentation parameters), they SHOULD use attributes defined by the OASIS WS-HumanTask specification. |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:47 AM ] |
| newProposedResolution |
[BPMNFTF-420] [OMG 14737] Exclusive Gateway Choreography Rule too Restrictive, starting new process
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-437 ##Original Info: (Severity: Significant - Nature: Revision) Filed for Dale Moberg. The rule illustrated by Figure 12-36 is that the choreography activities after an exclusive gateway must have the same receivers if the initiators are different. However, the receivers can be different if the activity starts a new process in the receiving participant, or if the receiving participant has access to the data in the decision from earlier in the flow. Steve says the discussions so far did not account for activites that start processes in the participants. |
| Comments |
| Comment by Conrad Bock (NIST) [ 25/Feb/09 10:17 AM ] |
|
From Steve's minutes:
Dale also brought up a problem with the rule defined in the Text Annotation in Figure 11-36. The rule is too restrictive. We need to clarify. The rule applies for some cases, but not others. If all the Ptps have seen a message with the appropriate data, then the rule could be relaxed. Basically all internal processes would be using data Decisions. Also, we didn't consider that a message could be the start of an internal Process for one of the Participants? However, if the receivers of the message (after the decision) didn't have access to the data, but had been previous part of the process, then there would be a problem. The internal process of those participants would be using an Event Gateway, but the Choreography Process would not contain the time out information for the internal process (so that it would not get stuck). Basically, we need to review the examples update how the rules are specified. |
| Comment by Conrad Bock (NIST) [ 23/Jul/09 08:45 AM ] |
|
Presumably this issue applies to inclusive gateways, because a similar
decision is made about which paths to split/merge. |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:59 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 02:03 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Defer The beta specification does not seem to have the restriction for exclusive gateways cited in the issue, but the filer is correct that the choreography enforcability rules do not account for the possibility of starting new processes in receivers. The issue is deferred for more discussion in RTF. |
[BPMNFTF-419] [OMG 14725] V0.9.9.1: Display of Messages and Associations in Choreography
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-482 ##Original Info: (Severity: Critical - Nature: Revision) This was generated from the example for BPMN-329. The current examples of Choreography show Messages connected to ChoreographyTasks through Associations. However, there are additional semantics to these connections. The semantics could be derived from the ChoreographyTask definiition, but we should investigate whether the display of the Message on the diagram requires any additional MM changes or whether this is purely a diagram display issue. Section 12, Beta 1 Spec ---------------------- Proposed Resolution -------- 2010-04-02 --------------------- ##Proposed Resolution: Fixed The resolution will clarify the use of the Message icon with Choreography Tasks. (a) Add a new paragraph below Figure 12.11: add new paragraph after the second paragraph (starting with "The three (3) bands...": "The Message sent by either one or both of the Participants of the Choreography Task can be displayed (see Figure 12.10, above). The Message icon is shown tethered to the Participant that is the sender of the Message." (b) After the new paragraph (item a), add a specification bullet (diamond bullet): "If the Message is the initiating Message of the Choreography Task, then the Message icon MUST be unfilled." (c) After the new bullet (item b), add a specification bullet (diamond bullet): "if the Message is a return Message for the Choreography Task, then the Message icon MUST have a light fill." (d) After the new bullet (item c), add a new paragraph: "Note that Messages can be tethered to a Call Choreography that references a GlobalChoreographyTask, but cannot be used for Sub-Choreographies or Call Choreography that references another Choreography." (e) Delete Figure 8.33 (f) Delete the paragraph above Figure 8.33 |
| Comments |
| Comment by Stephen White [ 23/Mar/10 01:52 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 23/Mar/10 01:55 PM ] |
|
-------------- Interactions Conference Call on 2010-03-23 --------------------------
Proposal withdrawn. This issue is not a duplicate of Issue 401 Text needs to be added to Restrict the display of Messages only with Choreography Tasks. Sections 12.4.1, 12.4.2, and 12.4.3 need to be updated |
| Comment by Stephen White [ 02/Apr/10 06:18 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 11/Apr/10 02:55 PM ] |
| Items (e) and (f) of the proposal were added on 2010-04-11 |
[BPMNFTF-418] [OMG 14740] Aliases for imported definitions
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| File Attachments: |
Credit Check Example V5.ppt
|
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-426 ##Original Info: (Severity: Significant - Nature: Revision) Filed for Martin and Steve, based on choreograph discussions. When importing definitions, names of imported elements might not be suitable for the application of the importing definitions. The importing definitions should be able to assign aliases to the imported elements for use within the importing definitions. ------------------------------------------------------------------------------------------------------------------- Proposal to review: [Suzette Samoojh - March 18, 2009] ------------------------------------------------------------------------------------------------------------------- Assumption: "Aliasing" is required when you need to use an existing element, but wish to label it differently based on a usage context. Two known use-cases: - A Participant references a Role (or Entity) and wishes to apply a name that is different from the Role (or Entity) name. - A CallActivity references a CallableElement and wishes to show a name that is different from the name of the CallableElement. Proposal: Use existing 'name' attributes to achieve this. - Participant.name: If specified, serves as the 'alias' for the referenced Role or Entity. If unspecified, the original name of the Role or Entity is used. - CallActivity.name [inherited from FlowElement]: Ditto No MM changes needed. Just spec text. If anyone has an example that the above does not satisfy, please post it. [Note that a concrete example then means we will tackle this issue in a samples-driven manner]. ------------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 11/Feb/09 11:49 PM ] |
| For example, a Process/Collaboration defines a Participant/Role named "Seller." This Process/Collaboration is called into another Process/Collaboration that has a Participant/Role named "Retailer." In the context of the parent, "Retailer" and "Seller" mean the same thing. This means that "Seller" needs have an alias to align it with "Relailer." |
| Comment by Conrad Bock (NIST) [ 12/Feb/09 10:11 AM ] |
|
I thought the use case for aliases was a role or entity in a defintions
file that imports another role or entity that happens to have a different name, but arethe same thing. For example, maybe an entity is "IBM" and the imported entity is "International Business Machines". The alias for the import could be "IBM". But this would cause a namespace conflict, if definitions are namespaces. Maybe it would be better to have some way of linking the entities to say they are the same thing, rather than depending on the name, not sure. |
| Comment by Conrad Bock (NIST) [ 17/Feb/09 03:47 PM ] |
| Steve suggests this should be available within the same definition file. |
| Comment by Dave Ings [ 10/Mar/09 11:06 AM ] |
| Steve suggested that it be assigned to Suzette and Suzette agreed. Suzette will consult with Steve on the use cases. |
| Comment by Suzette Samoojh (IBM) [ 15/Mar/09 06:49 PM ] |
|
The use-cases I'm aware of appear to have simple solutions. But it's possible I don't understand the full scope or all use-cases. For now, let me cover the ones that I know of, and their possible (seemingly simple) solutions.
Use-case 1: A Participant that references a Role/Entity, but which requires a contextual alias. Possible solution: Use the Participant.name attribute. If specified, it serves as the alias. If unspecified, the name is derived from the name of the Role or Entity. Use-case 2: A CallActivity that references CallableElement, and which requires a contextual alias. Possible solution: Use the inherited FlowElement.name attribute. If specified, it serves as the alias. If unspecified, the name is derived from the name of the CallableElement. |
| Comment by Suzette Samoojh (IBM) [ 18/Mar/09 03:51 PM ] |
| Attaching "Credit Check Example V5.ppt" for reference. But I don't believe this is a candidate for "aliasing" since, as stated on slide 12, the scenario covers two different Roles. |
| Comment by Conrad Bock (NIST) [ 19/Mar/09 11:11 AM ] |
|
Suzette,
The alias refers to the entities, roles, and processes/global tasks, rather than the participants and call activities. These might have different names in separately developed definition files, even thought they're the same thing in reality. I hink the suggestion is to support aliases on import (ie, the import itself will give a new name to the imported element in the receiving definition file). Conrad |
| Comment by Suzette Samoojh (IBM) [ 27/Mar/09 04:35 PM ] |
|
Reducing priority, since it looks like the new ParticipantAssociation class may address this requirement.
I won't close the issue just yet, in case we find that there is still need for more, beyond what the ParticipantAssociation covers. |
| Comment by Conrad Bock (NIST) [ 30/Mar/09 09:27 AM ] |
|
Suzette,
Lower priority is fine for me, although ParticipantAssociation does not address this really. ParticipantAssociation is for equating participants in certain situations, like calling choreographies, whereas the issue is about equating any elements in all situations. I expect the issue will be deferred. Conrad |
| Comment by Ivana Trickovic [ 09/Mar/10 11:14 PM ] |
|
As per March F2F Meeting:
- This is a request for a new feature. - So the proposal is to close (out of scope) the issue with no changes to the specification. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:13 PM ] |
|
##Proposed Resolution: Closed, Out Of Scope
This issue cannot be fixed in this FTF. |
[BPMNFTF-417] [OMG 14713] Beta 1 Section 2.2 Process Execution Conformance: Describe this conformance apart from Process Modeling Conformance
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-515 ##Original Info: (Severity: Minor - Nature: Enhancement) Add a description of how a tool might conform to Process Execution independent of Process Modeling Conformance. |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:33 AM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 12/Apr/10 08:13 AM ] |
|
##Proposed Resolution: Fixed
Make the following changes in section 2.2.1 Execution Semantics - Add the following text "The tool claiming Process Execution Conformance type is not expected to support Process Modeling Conformance. More precisely, the tool is not required to support graphical syntax and semantics defined in this specification. It MAY use different graphical elements, shapes and markers, then those defined in this specification." instead of "The tool claiming Process Execution Conformance type is not expected to support Process Modeling Conformance." |
| Comment by Ivana Trickovic [ 14/May/10 03:44 PM ] |
| Spec-Draft3-review |
| Comment by Ivana Trickovic [ 14/May/10 03:47 PM ] |
| The resolution is not included in the latest draft (Draft 3). |
| Comment by Ivana Trickovic [ 17/May/10 03:35 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 19/May/10 06:41 PM ] |
| Done |
[BPMNFTF-416] [OMG 14724] Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarification
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-events.doc
|
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-486 ##Original Info: (Severity: Minor - Nature: Enhancement) in the Concepts sub-section there is the following statement: "Signals are triggers generated in the Pool they are published." This is not clear. It implies that Signals are limited to being sent and received in the same Process, which is not true. ##Proposed Resolution: Fixed Section 10.4.1 Concepts 2nd paragraph Original They typically describe B2B communication. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals are triggers generated in the Pool they are published. Proposal They are generally used for B2B communication between different Processes in different Pools.. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals are triggers generated in the Pool they are published in. They are typically used for broadcast communication within and across Processes, across Pools, and between Business Process Diagrams. |
| Comments |
| Comment by Ivana Trickovic [ 22/Mar/10 06:06 PM ] |
|
proposalScheduledForBallot11
|
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:51 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:51 AM ] |
|
Section 10.4.1 Concepts
2nd paragraph Original They typically describe B2B communication. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals are triggers generated in the Pool they are published. Proposal They are generally used for B2B communication between different Processes in different Pools.. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals are triggers generated in the Pool they are published in. They are typically used for broadcast communication within and across Processes, across Pools, and between Business Process Diagrams. |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:52 AM ] |
| New Proposed Resolution |
[BPMNFTF-415] [OMG 14714] Beta 1 Section 12.4 Choreography Activities: Fix redundancy in the definition of these elements
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-506 ##Original Info: (Severity: Significant - Nature: Enhancement) There is some redundancy in the definition of Choreography Activities. For example, Participants are listed as well as MF, which have source and targer Participants. Also, for one-way Tasks, the initiating Participant can be derived from the MF. ##Proposed Resolution: Close; No Change The initiatingParticipantRef is necessary for non one-way Choreography Activities. Removing the ParticipantRefs would not allow modelers to create Choreography Activities before defining the Message Flow. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 07:30 PM ] |
| New Proposed Resolution |
[BPMNFTF-414] [OMG 14723] Beta 1: Section 10.4.5 Handling Events: When does the interrupting Event Sub-Process cancel its Parent?
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-events.doc
14_execsem.doc
uml-state.png
|
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-487 ##Original Info: (Severity: Critical - Nature: Enhancement) In this section there is the following text: "They execute synchronously and after their completion, the hosting Activity is immediately canceled." This means that the parent process will continue work while the Event SP is active, which could be a long time. If the triggering Event is an error, this doesn't make much sense. Note that the Execution Semantics section doesn't specify when the parent activity is terminated. ##Proposed Resolution: Fixed (a) * Section 10.4.6, p.257 Original: "They execute synchronously and after their completion, the hosting Activity is immediately terminated." Replace: "They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated." (b) * Section 10.4.6, p.257 Original: "The same restrictions apply for boundary Events." Append: "The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as normal." (c) * Section 10.4.6, p.258 Original: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is canceled." Replace: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted." (d) * Section 10.4.6, p.258 Original: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed." Append: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed. The parent Activity is canceled after either the error handler completes or Sequence Flow from the boundary Event is followed." (e) * Section 14.2.2, p.392 Original: Figure 14.2, missing addt'l states Failing and Terminating Replace: Figure 14.2, added states Failing and Terminating (f) * Section 14.2.2, p.393 Original: N/A Append: below bullet "• If an Activity's execution ends without anomalies, the Activity's state changes to Completing. [...]" --> the following text: "• An Activity's execution is interrupted if an interrupting Event is raised (such as an Error) or if an interrupting Event Sub Process is initiated, In this case, the Activity's state changes to Failing (in case of an Error) or Terminating (in case any other interrupting Event). All nested activities that are not in Ready, Active or a final state (Completed, Compensated, Failed, etc.) and non-interrupting Event Sub-Processes are terminated. The data context of the Activity is preserved in case an interrupting Event Sub-Process is invoked. The data context is released after the Event Sub-Process reaches a final state." (g) * Section 14.4.4, p.404 Original: "• A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. • An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in that Completing, no new Event Sub-Processes can be initiated." Replace: "•An Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The Event Handler may only be initiated after the parent Activity is Running. • More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. • Only one interrupting Event Handler may be initiated for a given Event Definition within the context of the parent Activity. Once the interrupting Event Handler is started, the parent Activity is interrupted and no new Event Handlers can be initiated or started.An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in that Completing, no new Event Sub-Processes can be initiated. • If an interrupting Event Sub-Process is started by an Error, then the parent Activity enters the state Failing and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no new Event Handlers may be started. • Similarly, if an interrupting Event Sub-Process is started by a Non Error (e.g., Escalation), then the parent Activity enters the state Terminating and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no new Event Handlers may be started." |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 03:18 AM ] |
|
As per March F2F Meeting:
Agreed to make the following changes: - The sentence referenced in the issue description shall be revised as word "synchronous" is misleading. - Cater for long running nature of activity termination and failure by adding "terminating" and "failing" states similar to the "completing" state. Add the behavior related to these states - In 14.2.2 describe what happens in case of activity interruption: all activities that are not in ready, active or a final state (completed, compensated, failed, etc.) and non-terminating event sub-processes are terminated. The interrupting event sub-process will complete. Similar for failing. - Add in section 14.4.4 (at the end of the paragraph) behavior for terminating and failing. Add a similar description as for "Completing", along the lines: for terminating, the activity remains in that state until the (interrupting) event-subprocess has completed. While the parent Activity is in terminating state, no new Event Sub-Processes can be initiated. Similar for the failing state. |
| Comment by Ivana Trickovic [ 22/Mar/10 06:00 PM ] |
| proposalScheduledForBallot10 |
| Comment by Karsten Ploesser (SAP) [ 29/Mar/10 04:22 AM ] |
| Uploaded files containing resolution proposal changes to events section, operational semantics, and changed activity state diagram |
| Comment by Karsten Ploesser (SAP) [ 29/Mar/10 04:23 AM ] |
| New Proposed Resolution |
| Comment by Mariano Benitez (Oracle) [ 29/Mar/10 08:16 AM ] |
|
##Proposed Resolution: Fixed
Uploaded files containing resolution proposal changes to events section, operational semantics, and changed activity state diagram. (Please update this resolution to include the exact changes). |
| Comment by Karsten Ploesser (SAP) [ 29/Mar/10 06:12 PM ] |
|
New Proposed Resolution
* Section 10.4.6, p.257 Original: "They execute synchronously and after their completion, the hosting Activity is immediately terminated." Replace: "They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated." * Section 10.4.6, p.257 Original: "The same restrictions apply for boundary Events." Append: "The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as normal." * Section 10.4.6, p.258 Original: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is canceled." Replace: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted." * Section 10.4.6, p.258 Original: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed." Append: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed. The parent Activity is canceled after either the error handler completes or Sequence Flow from the boundary Event is followed." * Section 14.2.2, p.392 Original: Figure 14.2, missing addt'l states Failing and Terminating Replace: Figure 14.2, added states Failing and Terminating * Section 14.2.2, p.393 Original: N/A Append: below bullet "• If an Activity's execution ends without anomalies, the Activity's state changes to Completing. [...]" --> the following text: "• An Activity's execution is interrupted if an interrupting Event is raised (such as an Error) or if an interrupting Event Sub Process is initiated, In this case, the Activity's state changes to Failing (in case of an Error) or Terminating (in case any other interrupting Event). All nested activities that are not in Ready, Active or a final state (Completed, Compensated, Failed, etc.) and non-interrupting Event Sub-Processes are terminated. The data context of the Activity is preserved in case an interrupting Event Sub-Process is invoked. The data context is released after the Event Sub-Process reaches a final state." * Section 14.2.2, p.404 Original: "• A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. • An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in that Completing, no new Event Sub-Processes can be initiated." Replace: "•An Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The Event Handler may only be initiated after the parent Activity is Running. • More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. • Only one interrupting Event Handler may be initiated for a given Event Definition within the context of the parent Activity. Once the interrupting Event Handler is started, the parent Activity is interrupted and no new Event Handlers can be initiated or started.An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in that Completing, no new Event Sub-Processes can be initiated. • If an interrupting Event Sub-Process is started by an Error, then the parent Activity enters the state Failing and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no new Event Handlers may be started. • Similarly, if an interrupting Event Sub-Process is started by a Non Error (e.g., Escalation), then the parent Activity enters the state Terminating and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no new Event Handlers may be started." |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:54 AM ] |
| New Proposed Resolution |
[BPMNFTF-413] [OMG 14704] optional source and target refs for data association
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
[OMG 14704] optional source and target refs for data association
##Source: Bruce Silver Associates (Bruce Silver, bruce@brsilver.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-525 ##Original Info: (Severity: Critical - Nature: Revision) dataOutputAssociation/@sourceRef should be optional, not required. dataInputAssociation/@targetRef should be optional, not required. This is to support non-executable models ( ------------------------ New Proposed Resolution ----------- 2010-01-22 ---------------------------- ##Proposed Resolution: Defer It was decided to wait until we have more user experience (i.e., complaints) about the issue. Thus we will defer the issue. ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 14/May/09 11:04 AM ] |
| Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text. The spec currently states that the source or target must be an ItemAwareElement. In the case of non-executable models, the source or target may be the FlowElement itself. So my proposal is to tweak the spec text, so as to allow this. |
| Comment by Stephen White [ 27/Jan/10 06:24 PM ] |
|
-------------------- Discussed during Conference Call on 2010-01-27 ---------------------
Do Data Associations need source and targets? It forces the user to model data inputs or outputs when making data associations -- since the connection is through them to the activity. Mostly the user shouldn't have to worry about it--modeling tool should handle it automatically. Is there really a burden on the user? For people manually creating XML, then yes. But most tools should be able to make it easy. We thought it best to defer it for now. If we get problems with implementations generating user complaints, then we can revist. |
| Comment by Stephen White [ 27/Jan/10 06:28 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-22 ----------------------------
It was decided to wait until we have more user experience (i.e., complaints) about the issue. Thus we will defer the issue. ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-412] [OMG 14705] parallelMultiple attribute missing from CatchEvent table
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-524 ##Original Info: (Severity: Significant - Nature: Revision) The CatchEvent has a "parallelMultiple" attribute, but it's not listed in the table in the spec. Table 10.75 on page 212 (242 pdf). ##Proposed Resolution: Fixed Add a row to Table 10.75 - CatchEvent attributes and model associations Attribute Name: parallelMultiple Description/Usage: This attribute is only relevant when the CatchEvent has more than event definition (Multiple). If this value is true, then all of the types of triggers that are listed in the CatchEvent MUST be triggered before the Process is instantiated. |
| Comments |
| Comment by Stephen White [ 23/Sep/09 04:52 PM ] |
| The Section and page numbers were added to match the Beta 1 spec. |
| Comment by Ivana Trickovic [ 10/Mar/10 04:35 AM ] |
|
As per March F2F Meeting:
- This is an editorial issue. The attribute is in the metamodel but not in the relating table. |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 11:20 AM ] |
|
Spec-Draft3-review
The change is included in the text but without change bars. |
| Comment by Stephen White [ 12/May/10 07:29 PM ] |
| Done |
[BPMNFTF-411] [OMG 14719] Beta 1: Section 10.3.1 Data Inputs and Outputs: Schema change: change minOccurs of inputSet for ioSpecification from 0 to 1
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-497 ##Original Info: (Severity: Minor - Nature: Revision) The spec says that there must be one InputSet for an ioSpecification. The schema has the minOcurrs at 0. The schema should be changed so that minOccurs is 1. -----------Proposal----------------01/12/2010---------------------------------------- ##Proposed Resolution: Fixed Spec update: Update the XSD snippet for tInputOutputSpecification (table 10.67) in the spec (a) <xsd:element ref="inputSet" minOccurs="1" maxOccurs="unbounded"/> (b) <xsd:element ref="outputSet" minOccurs="1" maxOccurs="unbounded"/> Note that the actual XSD is already correct. Only the snippet in the spec needs updating. ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 12/Jan/10 02:55 PM ] |
|
-----------Proposal----------------01/12/2010----------------------------------------
Spec update: Update the XSD snippet for tInputOutputSpecification (table 10.76) in the spec <xsd:element ref="inputSet" minOccurs="1" maxOccurs="unbounded"/> <xsd:element ref="outputSet" minOccurs="1" maxOccurs="unbounded"/> Note that the actual XSD is already correct. Only the snippet in the spec needs updating. |
| Comment by Mariano Benitez (Oracle) [ 12/Jan/10 03:21 PM ] |
| New Proposed Resolution: Fixed |
[BPMNFTF-410] [OMG 14706] The Category section has incorrect/inconsistent content
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Section8_constructs_ProposalFor410.doc
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-523 ##Original Info: (Severity: Significant - Nature: Revision) It states that the name of the Category provides the label for the Group. And yet Category does not have a name attribute. So where is the name coming from. Also, given that Group references CategoryValue (and not Category), shoudn't the Group label be the CategoryValue.value, rather than the Category name? In Figure 8-14, what is "Handle Medicine" ... is it a Category name or a CategoryValue.value? ##Proposed Resolution: Fixed Beta 1, August 2009 (pdf version) (a) Page 59: Change "The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. The grouping is tied to the Category supporting element (which is an attribute of all BPMN elements). That is, a Group is a visual depiction of a single Category. The graphical elements within the Group will be assigned the Category of the Group. (Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." to "The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. The grouping is tied to the CategoryValue supporting element. That is, a Group is a visual depiction of a single CategoryValue. The graphical elements within the Group will be assigned the CategoryValue of the Group. (Note -- CategorieValues can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." (b) Figure 8.14 - no change required (c) Figure 8.15 - The Group class diagram Add attribute "name" of type sting to class "Category". Change "categoryRef" to "categoryValueRef". - Update the XSD file accordingly. (d) Page 60: Change "The Group element inherits the attributes and model associations of BaseElement (see Table 8.5)." to "The Group element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to Artifact." (e) Table 8.21 - Group model associations Change categoryRef: Category [0..1] to categoryValueRef: CategoryValue [0..1] - Update the XSD file accordingly. Change: "The categoryRef attribute specifies the Category that the Group represents (Further details about the definition of a Category can be found on page 92). The name of the Category provides the label for the Group. The graphical elements within the boundaries of the Group will be assigned the Category." to "The categoryValueRef attribute specifies the CategoryValue that the Group represents (Further details about the definition of a Category and Category Value can be found on page 92 ). The label of the Group is provided by the value of the CategoryValue, optionally prepended by the Category name and delineator ":". The graphical elements within the boundaries of the Group will be assigned the CategoryValue." (f) Page 60: Change "Groups are one way in which Categories of objects can be visually displayed on the diagram. That is, a Group is a visual depiction of a single Category. The graphical elements within the Group will be assigned the Category of the Group. The Category name appears on the diagram as the Group label." to "Groups are one way in which Categories of objects can be visually displayed on the diagram. That is, a Group is a visual depiction of a single CategoryValue. The graphical elements within the Group will be assigned the CategoryValue of the Group. The value of CategoryValue, optionally prepended by the Category name and delineator ":", appears on the diagram as the Group label. " (g) Table 8.22 Category model associations Add row: Atttribute: name: string Description: The descriptive name of the element. (h) Page 61 Change "The Category element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.23 displays the attributes and model associations of the CategoryValue element." to "The CategoryValue element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.23 displays the attributes and model associations of the CategoryValue element." |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:35 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 29/Mar/10 06:55 AM ] |
|
------------------- Proposal ------------ 2010-03-29 -------------------------------------------------
##Proposed Resolution: Fixed The revised specification text is included in the Section8_constructs_ProposalFor410.doc. ---------------------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 29/Mar/10 06:55 AM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:44 AM ] |
|
The following suggestion has been made:
- Make the delineator a suggestion rather than the only label. Simply because people aren't used to this style. - Use ":" rather than "." The ":" is a little more common for business models - Instead of: "The name of the Category and the value of the CategoryValue separated by delineator "." provide the label for the Group." Add something like: "The label for the Group is provided by the value of the CategoryValue, optionally prepended by the Category name and a ":" delineator." The proposed resolution will be updated accordingly. |
| Comment by Ivana Trickovic [ 05/Apr/10 05:12 PM ] |
|
The issue resolution updated to address the feedback.
1. No need to make change (b), so it is removed from the proposal: (b) Figure 8.14 - A Group around Activities in different Pools Change Group label "Handle Medicine" to "BusinessActivity.HandleMedicine" 2. Include "The categoryValueRef attribute specifies the CategoryValue that the Group represents (Further details about the definition of a Category and Category Value can be found on page 92 ). The label of the Group is provided by the value of the CategoryValue, optionally prepended by the Category name and delineator ":". The graphical elements within the boundaries of the Group will be assigned the CategoryValue." Instead of: The categoryValueRef attribute specifies the CategoryValue that the Group represents (Further details about the definition of a Category and Category Value can be found on page 92 ). The name of the Category and the value of the CategoryValue separated by delineator "." provide the label for the Group. The graphical elements within the boundaries of the Group will be assigned the CategoryValue 3. Include "Groups are one way in which Categories of objects can be visually displayed on the diagram. That is, a Group is a visual depiction of a single CategoryValue. The graphical elements within the Group will be assigned the CategoryValue of the Group. The value of CategoryValue, optionally prepended by the Category name and delineator ":", appears on the diagram as the Group label. " Instead of "Groups are one way in which Categories of objects can be visually displayed on the diagram. That is, a Group is a visual depiction of a single CategoryValue. The graphical elements within the Group will be assigned the CategoryValue of the Group. The Category name augmented by the value of the CategoryValue appears on the diagram as the Group label. " |
| Comment by Ivana Trickovic [ 14/May/10 03:48 PM ] |
| Spec-Draft3-review |
| Comment by Ivana Trickovic [ 14/May/10 03:49 PM ] |
|
The following changes should be made:
(1) pdf, page 59: change "The grouping is tied to the CategoryValue supporting element (which is an attribute of all BPMN elements). That is, a Group is a visual depiction of a single Category." to "The grouping is tied to the CategoryValue supporting element. That is, a Group is a visual depiction of a single CategoryValue. " (2) pdf, page 61: change "The Category name, augmented by the value of the CategoryValue, appears on the diagram as the Group label." to "The value of CategoryValue, optionally prepended by the Category name and delineator ":", appears on the diagram as the Group label. " |
| Comment by Ivana Trickovic [ 17/May/10 03:34 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 19/May/10 06:38 PM ] |
| Done |
[BPMNFTF-409] [OMG 14718] XSD DataAssociation should own source and target refs and mistake in text spec
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Section 10 - Process V5 - mb-may5.doc
|
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-501 ##Original Info: (Severity: Significant - Nature: Revision) According to the spec text, DataInputAssociation and DataOutputAssociation do not define any attribute. In the XSD they both own define sourceRef and TargetRef. These elements should be part of the parent class. (there is no problem in moving them up since both definitions are similar (cardinality and types). Also: In page 202 of Beta 1 it says: "The DataInputAssociation element inherits the attributes and model associations of *FlowElement* (see Table 10-62), but does not contain any additional attributes or model associations." But it should say DataAssociation. ##Proposed Resolution: Fixed Section 10.3.1 For both DataInputAssociation and DataOutputAssociation paragraphs, replace FlowElement (see Table 10.58), with DataAssociation (see Table 10.57). In XML Schemas: Table 10.64 DataAssociation XML Schema, add the following elements: <xsd:element name="sourceRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/> <xsd:element name="targetRef" type="xsd:QName" minOccurs="1" maxOccurs="1"/> Table 10.66 DataInputAssociation XML Schema and Table 10.71 - DataOutputAssociation XML schema, remove the following: <xsd:sequence> <xsd:element name="sourceRef" type="xsd:IDREF" minOccurs="1" maxOccurs="unbounded"/> <xsd:element name="targetRef" type="xsd:IDREF" minOccurs="1" maxOccurs="1"/> </xsd:sequence> |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 05/May/09 09:05 AM ] |
| Proposal for text fix, just replace flowelement with dataassociation. |
| Comment by Mariano Benitez (Oracle) [ 05/May/09 09:06 AM ] |
|
Steve, I just attached the fix for the text issue, can you apply it?
Regarding the MM (XSD) change, it's not that critical to add it, but it could help. |
| Comment by Ivana Trickovic [ 06/May/09 04:27 AM ] |
| As per 5/4 BPMN team meeting - the issue is valid but to be deferred. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:59 PM ] |
| proposalScheduledForBallot11 |
| Comment by Antoine Toulme (Intalio) [ 08/Apr/10 03:20 PM ] |
|
This change is invalid. As of |
| Comment by Mariano Benitez (Oracle) [ 08/Apr/10 03:35 PM ] |
|
actually it should be updated once 404 is applied, and applied them both correctly.
This issue is about moving source and target to the parent class, the other issue is about the cardinality, different issues. Anyway, when we apply the issue, it should be properly reflected in the document. The change would be to use this snippet: <xsd:element name="sourceRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> |
| Comment by Antoine Toulme (Intalio) [ 08/Apr/10 04:43 PM ] |
|
OK. I was under the impression that the fix for |
[BPMNFTF-408] [OMG 14710] V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-activities -- Issue 408.doc
10_process-general -- Issue 408.doc
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-519 ##Original Info: (Severity: Critical - Nature: Revision) The Process does not have a way to have a resource, e.g., a supervisor, assigned. Thus, a ProcessResouce, similar to the ActivityResource, should be added. ##Proposed Resolution: Fixed (a) Change the name of the ActivityResource element to ResourceRole (b) Update Figures 10.6, 10.7, 10.20, 10.21, and 10.22 to reflect this name change (c) Update Table 10.3, row 3, to reflect this name change (d) Update Section 10.2.1, Sub-Section ActivityResource, to reflect this name change. Five (5) changes are required. (e) Update Section 10.2.1, Sub-Section Expression Assignment, to reflect this name change. Two (2) changes are required. (f) Update Section 10.2.2, to reflect this name change. One (1) change is required. (g) Update Section 10.2.4, Sub-Section Human Performers, to reflect this name change. One (1) change is required. (h) Update Table 10.29 to reflect this name change. One (1) change is required. (i) Update Table 10.30 to reflect this name change. Four (4) changes are required. (j) Update Table 10.135 to reflect this name change. Two (2) changes are required. (k) The Process element can now contain zero (0) to many ResourceRole elements. (l) Update Figures 10.3 and 10.7 to reflect this change Add one row to Table 10.1 (m) The first column of the new row for Table 10.1 will have the following text: "resources: ResourceRole [0..*]" (n) The second column of the new row for Table 10.1 will have the following text: "Defines the resource that will responsible for or in some way associated with the Process. The resource, e.g., a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization. Note that the assigned resources of the Process does not determine the assigned resources of the Activities that are contained by the Process. See more details about resource assignment in Section 10.2.1" (o) Add the following text to Table 10.129: "<xsd:element ref="ResourceRole" minOccurs="0" maxOccurs="unbounded"/>" |
| Comments |
| Comment by Stephen White [ 23/Sep/09 05:04 PM ] |
| This is suitable for the FTF |
| Comment by Stephen White [ 11/Feb/10 01:24 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
Add a Resource attribute to Process Only on Activity now Not Top-level Adding one attribute the Process Same semantics as for activities There was a Performer attribute in V1.2. So, there should be backward compatibility. A proposal will be generated |
| Comment by Ivana Trickovic [ 09/Mar/10 08:16 AM ] |
|
As per March F2F Meeting:
Following questions to be discussed: - Relationship between Resource and Performer on the process level is not clear. Do we need to introduce Resource or Performer? - Do we need to introduce overriding rules for resource and/or performer on the activity level? |
| Comment by Stephen White [ 22/Mar/10 07:23 PM ] |
| proposalScheduledForBallot10 |
| Comment by Stephen White [ 24/Mar/10 08:52 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 01/Apr/10 06:18 PM ] |
|
------------- Conference Calls on 2010-03-24 and 2010-03-31 ------------------------
Resource for Process is required -- partly because it was in 1.x There is an ActivityResource Class, but that name would not be appropriate for Process Process is not an activity in the MM Rename ActivityResource class AssignedResource ? ResourceRole ? Parallels with PartnerRole There is also precedent for using Role in this way from WSHumanTask Change to ResourceRole and allow Process to contain it as well. Add clarification about role on process (i.e., does not impact the resourceroles of the activities within the Process). |
| Comment by Mariano Benitez (Oracle) [ 17/May/10 10:21 AM ] |
|
Spec-Draft3-review
In Table 2.4 - Common Executable Conformance Sub-Class Supporting Classes (page 38 pdf) ActivityResource was not renamed to ResourceRole |
| Comment by Ivana Trickovic [ 17/May/10 03:40 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 19/May/10 06:22 PM ] |
| Done |
[BPMNFTF-407] [OMG 14722] TimerEventDefinition: clarification of the expected result of the timeCycle and timeDate expressions
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-events.doc
|
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-489 ##Original Info: (Severity: Significant - Nature: Revision) These attributes of the TimerEventDefinition are expressions, there is no mention of the result type. Also it would be useful to describe how this values are used (timeDate defines the next moment the time will trigger, while timeCycle defines an interval that is added to "now" to define the next moment). Another thing that is not described is the moment when theses expressions are evaluated. Intuitively I think it is in the moment after the trigger is executed, and for the first time, the moment it is activated. Following the BPEL mapping, the timeDate expression should return an XSD DateTime element and the timeCycle an XSD Interval (Period). I think it is necessary to clarify this in the execution semantics so people understand what type of behaviour is expected from this event. I can make the changes if necessary. ##Proposed Resolution: Fixed Section 10.4.5 Event Definitions Subsection Timer Event, Table 10.20 - TimerEventDefinition model associations > Change row: attribute timeDate Original If the Trigger is a Timer, then a timeDate MAY be entered. If a timeDate is not entered, then a timeCycle MUST be entered (see attribute below—if the processType attribute of the Process is set to executable). Proposal If the Trigger is a Timer, then a timeDate MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeDate MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDate MUST conform to the ISO-8601 format for date and time representations. > Change row: attribute timeCycle Original If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDate MUST conform to ISO-8601 interval format. Proposal If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeCycle MUST conform to the ISO-8601 format for recurring time interval representations. > Append row: attribute timeDuration Original N/A Proposal Attribute Name timeDuration: Expression [0..1] Description/Usage If the Trigger is a Timer, then a timeDuration MAY be entered to specify a relative point in time. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeDuration MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDuration MUST conform to the ISO-8601 format for time interval representations. |
| Comments |
| Comment by Rouven Day (SAP) [ 08/Mar/10 09:27 AM ] |
|
>"there is no mention of the result type"
Seems to be not an issue since any formal expression has an result type from which one can get the result type. |
| Comment by Mariano Benitez (Oracle) [ 08/Mar/10 12:34 PM ] |
|
right, but there is no specification of what type is that, so your expression can return any type, consequently the runtime will not know what to do with it. "e.g. an expression returns a string "tomorrow", are all engines expected to understand that?"
I would like the spec to specify the result type, a date time or an interval. |
| Comment by Ivana Trickovic [ 10/Mar/10 03:32 AM ] |
|
As per March F2F Meeting:
- The return value of timeDate attribute(format) has to confirm to ISO-8601 (http://www.iso.org). - Similar for the other attribute: timeCycle. - Add additional attribute for duration. - The three attributes are mutually exclusive. |
| Comment by Ivana Trickovic [ 22/Mar/10 06:05 PM ] |
| proposalScheduledForBallot11 |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:49 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:50 AM ] |
|
Section 10.4.5 Event Definitions
Subsection Timer Event, Table 10.20 - TimerEventDefinition model associations > Change row: attribute timeDate Original If the Trigger is a Timer, then a timeDate MAY be entered. If a timeDate is not entered, then a timeCycle MUST be entered (see attribute below—if the processType attribute of the Process is set to executable). Proposal If the Trigger is a Timer, then a timeDate MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeDate MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDate MUST conform to the ISO-8601 format for date and time representations. > Change row: attribute timeCycle Original If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDate MUST conform to ISO-8601 interval format. Proposal If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeCycle MUST conform to the ISO-8601 format for recurring time interval representations. > Append row: attribute timeDuration Original N/A Proposal Attribute Name timeDuration: Expression [0..1] Description/Usage If the Trigger is a Timer, then a timeDuration MAY be entered to specify a relative point in time. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeDuration MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDuration MUST conform to the ISO-8601 format for time interval representations. |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:50 AM ] |
| New Proposed Resolution |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:49 AM ] |
|
Table 10.101 - TimerEventDefinition model associations
UPDATE row (timeDuration: Expression[0..1]) • Current version: "The return type of the attribute timeDuration MUST conform to the ISO-8601 format for recurring time interval representations." • Remove "recurring" i.e. change text to "time interval representations" |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:50 AM ] |
|
Draft 3 bugfix required:
Table 10.101 - TimerEventDefinition model associations UPDATE row (timeDuration: Expression[0..1]) • Current version: "The return type of the attribute timeDuration MUST conform to the ISO-8601 format for recurring time interval representations." • Remove "recurring" i.e. change text to "time interval representations" |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:50 AM ] |
| Spec-Draft3-review |
| Comment by Ivana Trickovic [ 17/May/10 03:33 PM ] |
| As per the meeting of May 17th: Agreed that this needs to b fixed |
| Comment by Stephen White [ 19/May/10 06:17 PM ] |
| Done |
[BPMNFTF-406] [OMG 14709] Multiple processes per participant
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 1 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-520 ##Original Info: (Severity: Critical - Nature: Revision) From side discussion with Frank: A single public interaction (choreography, collaboration, or conversation) might be supported by multiple internal processes, but the current metamodel only allows one process per participant. The multiplicity should be widened to *. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 03:37 PM ] |
| Reduced Priority from Critical to Major |
| Comment by Stephen White [ 25/Mar/10 06:24 PM ] |
|
------------- Conference Call on 2010-03-25 ------------------------------
The situation could be handled by putting the Processes in separate Pools. The Pools would all have the same Partner Entity, but have different Partner Roles. If Partner Entity are not desirable, we would have to set up a way to have hierarchical Partner Roles to do the same thing. Putting multiple Processes in one Pool would have challenges We also noted that any Process can have multiple Start Events now. Thus, it might be hard distinguish multiple Processes with a Process with multiple Start Events. We do not think we can come up with a solution during the FTF Thus, we recommend to defer. |
| Comment by Stephen White [ 25/Mar/10 06:25 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:38 PM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:29 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Defer It should be possible for a collaboration to require support of more than one process in a participant. This is deferred for more discussion in RTF on a solution. |
[BPMNFTF-405] [OMG 14715] Beta 1 Section 13.2.4 ChoreographyActivityShape: Add Choreography Activity Bands to DI model
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Denis Gagne |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-505 ##Original Info: (Severity: Critical - Nature: Revision) The current DI model doesn't specify the Participant Bands of the shape and should be added. These bands can vary in shading and Association connections to the shape (of a Message) are dependent on the sender of the Message (i.e., the Participant of the appropriate Band). |
| Comments |
| Comment by Ivana Trickovic [ 06/May/09 03:41 AM ] |
| As per 5/4 BPMN team meeting - the issue to be deferred. |
| Comment by Denis Gagne [ 10/Mar/10 09:50 AM ] |
|
BPMN DI F2F March 10
We need to introduce a band shape (BPMNShape) that will refer to a particpant. This band will offer a source and target for message flows (IT IS NOT CLEAR IN THE SPEC WETHER THE BANDS ARE THE SOURCE AND TARGET OF MESSAGE FLOWS WHEN MANY BANDS ARE PILED UP) This band can be shaded for initiating purposes. **This is a potential use case for maintenaining the minimum cotainment of the baseline proposal. Because a BPMNDI:BPMNShape referencing a Participarnt could be rendered many ways (e.g. Pool or a Band on a Choreography activity, ...) |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:33 PM ] |
|
##Proposed Resolution: Close, No Change
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-404] [OMG 14717] DataAssociations: How do we support literals?
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-502 ##Original Info: (Severity: Critical - Nature: Revision) DataAssociations and Assigments correctly allow mapping between data elements. Now, there is no way to do a simple mapping of a literal to a data input. An assignment could be used to solve the problem, but then you are forced to include a dummy sourceRef to fullfil the requirement of at least one source ref. A simple solution would be to allow 0 zero source refs, and keeping the restriction of the scope of the assignment to the souce refs. ----Proposal---------------- 02/16/2010 ------------------------- ##Proposed Resolution: Fixed (a) Update the UML metamodel, changing the multiplicity of DataAssociation.sourceRef from 1..* to 0..* Replace Figure 10.61 (pg 230) (b) Update Table 10.57 (pg 231) Change the multiplicity of the sourceRef association to 0..* (c) Update Tables 10.64, 10.66, 10.71 (schema snippets) to match the updated metamodel |
| Comments |
| Comment by Ivana Trickovic [ 06/May/09 04:28 AM ] |
| As per 5/4 BPMN team meeting - the issue is valid but to be deferred. |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:33 PM ] |
|
I agree with the recommendation to change the source multiplicity to 0..n (is currently 1..n).
Suggest this becomes a formal proposal. |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:29 AM ] |
|
-----Proposal---------------- 02/16/2010 -------------------------
##Proposed Resolution: Fixed (a) Update the UML metamodel, changing the multiplicity of DataAssociation.sourceRef from 1..* to 0..* Replace Figure 10.61 (pg 230) (b) Update Table 10.57 (pg 231) Change the multiplicity of the sourceRef association to 0..* (c) Update Tables 10.64, 10.66, 10.71 (schema snippets) to match the updated metamodel |
| Comment by Stephen White [ 17/Feb/10 06:11 PM ] |
| New Proposed Resolution |
[BPMNFTF-403] [OMG 14707] Editorial: Incorrect containment statement for EventDefinitions
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-522 ##Original Info: (Severity: Minor - Nature: Revision) Section 10.4.5 Event Definitions Beta 1 spec page 238 (268 pdf) states that: "When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions." This is of course incorrect, since an EventDefinition can be contained by either the Definitions or the Catch/ThrowEvent. ---------------------- Proposed Resolution -------- 2010-01-20 --------------------- ##Proposed Resolution: fixed Change the paragraph to: "When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined, it is either a reusable event definition contained in Definitions, or a contained event definition contained in a Throw/Catch Event." ------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 23/Sep/09 05:03 PM ] |
| The page number was updated to match the Beta 1 spec |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 07:50 AM ] |
|
There is also a typo in p. 213 (pdf p. 243) in Table 10.76 ThrowEvent attributes and model associations:
In the eventDefinitionRefs attribute, the paragraph says: "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a throw Event." where it is not "triggers" but "results". So the paragraph should say: "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable *results* expected for a throw Event." Another typo in the same page: "Table 10.76 presents the additional attributes and model associations of the CatchEvent element." when it should say: "Table 10.76 presents the additional attributes and model associations of the *ThrowEvent* element." |
[BPMNFTF-402] [OMG 14708] Notation for supports association
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-521 ##Original Info: (Severity: Significant - Nature: Revision) Filed for Frank: The supports association between processes should have a notation. ------------- New Proposed Resolution ----- 2010-02-15 ------------- ##Proposed Resolution: Close; Out of Scope Close; Out of Scope. The issue requests a notation that would require a new diagram added to BPMN. While there might be value in such a diagram, it is out of scope for the FTF or any RTFs. --------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 03/Feb/10 04:31 PM ] |
|
-------------------- Discussion during Converence call on 2010-02-03 -----------------------
This is a request for notation for support association between processes It would need to create a new diagram that shows the relationship between processes Out of scope for FTF. Defer for new RFP work |
| Comment by Stephen White [ 03/Feb/10 04:32 PM ] |
|
------------- New Proposed Resolution ----- 2010-02-03 -------------
Defer. The issue requests a notation that would require a new diagram added to BPMN. While there might be value in such a diagram, it is out of scope for the FTF --------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 15/Feb/10 12:15 PM ] |
|
------------- New Proposed Resolution ----- 2010-02-15 -------------
Close; Out of Scope. The issue requests a notation that would require a new diagram added to BPMN. While there might be value in such a diagram, it is out of scope for the FTF or any RTFs --------------------------------------------------------------------------------------- |
[BPMNFTF-401] [OMG 14716] Metaelement missing for DI to show connection between ChoreographyActivity to Message
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Denis Gagne |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-504 ##Original Info: (Severity: Critical - Nature: Revision) The metamodel does not have a element for DI to use for connecting ChoreographyActivity and Message (derivable from ChoreographyActivity to Message Flow to Message). Associations should not be used for links that are derivable from the semantic metamodel. |
| Comments |
| Comment by Ivana Trickovic [ 06/May/09 03:38 AM ] |
| As per 5/4 BPMN team meeting - the issue to be deferred. |
| Comment by Mariano Benitez (Oracle) [ 09/Mar/10 04:19 AM ] |
|
-- Per the F2F discussion March 9th
- This is an interaction issue - Once the interation sub-team decides the semantics, the DI team wil find a representation. Assign to Steve as Interaction sub-team lead. |
| Comment by Stephen White [ 22/Mar/10 07:18 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 23/Mar/10 01:43 PM ] |
|
-------------- Interactions Conference Call on 2010-03-23 --------------------------
No semantic changes are necessary. This is not an interaction issue. A tool should be able to determine the location of the Message (and tether) through the source of Message's Message Flow defined for the Choreography Task. Reassigned to the DI team. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:34 PM ] |
|
##Proposed Resolution: Close, No Change
This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue |
[BPMNFTF-400] [OMG 14720] tActivityResource::resourceRef should be optional
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-494 ##Original Info: (Severity: Significant - Nature: Revision) tActivityResource::resourceRef is a required attribute, but should be optional - in case the resource is resolved via a ResourceAssigmnentExpression there won't be any statically assigned resourceRef (except for a dummy, which is how I resolved the problem in the example). <performer resourceRef="dummy"> <!--Issue: If specified via an expression, a resourceRef is not needed, i.e., the attribute must not be required.--> <resourceAssignmentExpression> <formalExpression>getInputData()/resource</formalExpression> </resourceAssignmentExpression> </performer> |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 10:44 AM ] |
|
Given we have not described the semantics of having both a resourceRef and a resourceAssignmentExpression, should we take this further and treat them as mutually exclusive (as opposed to simply making the resourceRef optional).
Hence, an ActivityResource may have one of the following: - A resourceRef and optional resourceParameterBindings, or - A resourceAssignmentExpression The XSD would then represent such exclusivity using a choice. <xsd:complexType name="tActivityResource"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:choice> <xsd:sequence> <xsd:element name="resourceRef" type="xsd:QName"/> <xsd:element ref="resourceParameterBinding" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:element ref="resourceAssignmentExpression" minOccurs="0" maxOccurs="1"/> </xsd:choice> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:00 AM ] |
|
-----Proposal---------------- 02/16/2010 -------------------------
##Proposed Resolution: Fixed (a) Replace Figure 10.7 (pg 161) Update the UML metamodel, giving the ActivityResource.resourceRef association a multiplicity of [0..1] (b) Update Table 10.5 (pg 162) Specify a multiplicity of [0...1] for the resourceRef association New description for resourceRef: The Resource that is associated with the Activity. Should not be specified when a resourceAssignmentExpression is provided. Append to description for resourceAssignmentExpression: Should not be specified when a resourceRef is provided. Append to description for resourceParameterBindings: Is only applicable if a resourceRef is specified. (c) Update Table 10.30 (pg 175) Replacement XSD snippet <xsd:complexType name="tActivityResource"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:choice> <xsd:sequence> <xsd:element name="resourceRef" type="xsd:QName"/> <xsd:element ref="resourceParameterBinding" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:element ref="resourceAssignmentExpression" minOccurs="0" maxOccurs="1"/> </xsd:choice> </xsd:extension> </xsd:complexContent> </xsd:complexType> [Note: a consequence of formalizing in the XSD as a 'choice' is that the resourceRef is now an element instead of an attribute] (d) Update Table 10.19 (pgs 181-182) Replace the 'resourceRef' attributes with equivalent 'resourceRef' elements. |
| Comment by Stephen White [ 08/Mar/10 10:10 PM ] |
| New Proposed Resolution |
[BPMNFTF-399] [OMG 14712] Use "item" terminology more uniformly
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-517 ##Original Info: (Severity: Critical - Nature: Revision) Steve, > Terminology is perhaps the hardest part of standards such as BPMN. There is no way to pick terms that will be acceptable to all potential users of BPMN. Different groups will come into BPMN with different expectations. Some of the terms will fit those expectations and other will not. > [From http://www.omg.org/archives/bpmn2-eval/msg00048.html] In this particular case, the submission has one already ("item", as in ItemDefinition, ItemAwareElement, and ItemKind), introduced to accomodate informational and physical flows. I think it would be good to have uniform terminology covering both information and physical things, for example: Message Flow => Item Flow (Message appears redundant with ItemDefinition, or Message could be a subclass of ItemDefinition for those items that happen to be used in Item Flows) Data Object => Item Object DataInput => ItemInput DataOutput => ItemOutput DataState => ItemState DataAssociations => ItemAssociations So much of BPMN's market is modeling businesses in general rather than business software specifically, that I think it's important for adoption to have the appropriate terminology. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 08:27 AM ] |
|
As per March F2F Meeting:
- This is not an implementation issue so we agreed to lower the priority - With this change we would lose semantics, so the proposal is to close this with no changes to the specification. |
| Comment by Stephen White [ 09/Mar/10 10:39 AM ] |
|
One simple change could be:
DataInput => Input DataOutput => Output This would match better with InputSet, OutputSet, and InputOutputSpecification |
| Comment by Conrad Bock (NIST) [ 09/Mar/10 12:43 PM ] |
|
March F2F,
> - This is not an implementation issue so we agreed to lower the > priority. Usability issues are as high priority as implementation. > - With this change we would lose semantics, so the proposal is to > close this with no changes to the specification. This regards terminology (usability in naming), not semantics (ie, the business/platform will not function differently because of the names). Conrad |
| Comment by Conrad Bock (NIST) [ 09/Mar/10 02:36 PM ] |
|
Mariano,
This issue was assigned to me, can you remove the proposal? Sorry I'm not able to be at the FTF. Conrad |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:18 PM ] |
| Removing from Ballot to allow Conrad to make proposal |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:59 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 07/Apr/10 10:34 AM ] |
|
-----------Proposal----------------Apr 7, 2010---------------------------
##Proposed Resolution: Closed, No Change DataInputs/Outputs/Objects, Messages, and other BPMN elements can be physical, as defined in ItemDefinition, and it would be better if the names reflected that possibility. However, implementations are too far along to change at this point. |
[BPMNFTF-398] [OMG 14711] Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | WS-BPEL Mapping |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-518 ##Original Info: (Severity: Minor - Nature: Revision) The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition. This figure should be updated. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 03:06 PM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comment by Ivana Trickovic [ 04/Apr/10 11:39 PM ] |
| This is an editorial issue. Move it on ballot #12. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-397] [OMG 14721] Correlation properties must have name and type (was dropped in 4/22 XSD and MM)
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-493 ##Original Info: (Severity: Significant - Nature: Revision) Correlation properties are specified by means of name and type, e.g., orderID of type integer, or customerName of type string. The properties may typically be specified by means of their name and type only, while retrievalExpressions are added only later, and modified independently. The latest version of the spec dropped name and type. Resolution proposal: Re-add correlationProperty::name and ::itemRef. ------------------- Proposal ------------ 2010-02-17 ------------------------ ##Proposed Resolution: Fixed UML Schema (a) -- Add attributes as per XSD above/spec table changes below Specification text: -- Figure 8.18 Correlation Class diagram Show the following added attributes in their compartments: (b) CorrelationKey::name (c) CorrelationProperty::name (d) CorrelationProperty::type -- Table 8.32 CorrelationKey model associations Add the following row: (e) name[0..1] | String | Specifies the name of the correlation key -- Table 8.33 CorrelationProperty model associations Add the following rows: (f) name[0..1] | String | Specifies the name of the correlation property (g) type[0..1]='String' | ItemDefinition | Specifies the type of the correlation property ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 08/Feb/10 07:18 AM ] |
|
(Related to The following is a snippet from the correlation of the standard seller example, using names and types on correlation properties, and names correlation keys. Search for "issue" to find the spots with the proposed changes in the example. <!--===================================================================== Collaboration: Seller entity ("concrete" participant) and Buyer/Shipper role ("abstract"/prototypical participants) =====================================================================--> <partnerEntity id="theSeller" name="The Seller"/> <partnerRole id="aBuyer" name="A Buyer"/> <partnerRole id="aShipper" name="A Shipper"/> <!--Issue Issue Proposal: Add attributes 'name' and 'type' as attributes to the schema. Name is optional with no default, type is optional and defaults to xsd:string.--> <correlationProperty id="propQuoteID" name="Property Quote ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgRFQ"> <messagePath>/request/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgQuote"> <messagePath>/response/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgFault"> <messagePath>/fault/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/priceQuotationRef</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <correlationProperty id="propCustomerID" name="Property Customer ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/customer/id</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderConfirmation"> <messagePath>/customerID</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <correlationProperty id="propOrderID" name="Property Order ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/order/orderID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderConfirmation"> <messagePath>/order/orderID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgShippingData"> <messagePath>tbd</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgShippingConfirmation"> <messagePath>tbd</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <collaboration id="sellerCollab"> <participant id="seller" name="Seller" partnerEntityRef="tns:theSeller" processRef="tns:sellerProcess"> <interfaceRef>tns:sellerServiceInterface</interfaceRef> </participant> <participant id="buyer" name="Buyer" partnerRoleRef="tns:aBuyer"/> <participant id="shipper" name="Shipper" partnerRoleRef="tns:aShipper"> <interfaceRef>tns:shipperServiceInterface</interfaceRef> </participant> <messageFlow id="mf1" messageRef="tns:msgRFQ" sourceRef="tns:aBuyer" targetRef="tns:receiveQuoteRequest"/> <messageFlow id="mf2" messageRef="tns:msgQuote" sourceRef="tns:sendQuote" targetRef="tns:aBuyer"/> <messageFlow id="mf3" messageRef="tns:msgFault" sourceRef="tns:sendFault" targetRef="tns:aBuyer"/> <messageFlow id="mf4" messageRef="tns:msgOrderData" sourceRef="tns:aBuyer" targetRef="tns:receiveOrderRequest"/> <messageFlow id="mf5" messageRef="tns:msgOrderConfirmation" sourceRef="tns:sendOrderResponse" targetRef="tns:aBuyer"/> <messageFlow id="mf6" messageRef="tns:msgShippingData" sourceRef="tns:sendShippingRequest" targetRef="tns:aShipper"/> <messageFlow id="mf7" messageRef="tns:msgShippingConfirmation" sourceRef="tns:aShipper" targetRef="tns:receiveShippingConfirmation"/> <!--===================================================================== Conversations =====================================================================--> <conversation id="conversationQuoteRequest"> <messageFlowRef>tns:mf1</messageFlowRef> <messageFlowRef>tns:mf2</messageFlowRef> <messageFlowRef>tns:mf3</messageFlowRef> <messageFlowRef>tns:mf4</messageFlowRef> <!--Issue Proposal: Add attribute 'name' as attribute to the schema. Name is optional with no default.--> <correlationKey id="correlQuote" name="Quote CorrelationKey"> <correlationPropertyRef>tns:propQuoteID</correlationPropertyRef> </correlationKey> </conversation> <conversation id="conversationOrderHandling"> <messageFlowRef>tns:mf4</messageFlowRef> <messageFlowRef>tns:mf5</messageFlowRef> <correlationKey id="correlOrder" name="Order Correlation Key"> <correlationPropertyRef>tns:propCustomerID</correlationPropertyRef> <correlationPropertyRef>tns:propOrderID</correlationPropertyRef> </correlationKey> </conversation> <conversation id="conversationShipmentRequest"> <messageFlowRef>tns:mf6</messageFlowRef> <messageFlowRef>tns:mf7</messageFlowRef> <correlationKey id="correlShipment" name="Shipment Correlation Key"> <correlationPropertyRef>tns:propOrderID</correlationPropertyRef> </correlationKey> </conversation> </collaboration> Derived from the example, here are the required changes in the XSD: <xsd:element name="correlationKey" type="tCorrelationKey"/> <xsd:complexType name="tCorrelationKey"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element name="correlationPropertyRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"><!-- New for issue </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="correlationProperty" type="tCorrelationProperty" substitutionGroup="rootElement"/> <xsd:complexType name="tCorrelationProperty"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:sequence> <xsd:element ref="correlationPropertyRetrievalExpression" minOccurs="1" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"><!-- New for issues <xsd:attribute name="type" type="xsd:QName" default="xsd:string" use="optional"><!-- New for issue </xsd:extension> </xsd:complexContent> </xsd:complexType> Textual changes will be specified in detail after the outline of this proposal has been discussed and agreed upon. |
| Comment by Matthias Kloppmann (IBM) [ 09/Feb/10 08:46 AM ] |
|
Here are the remaining required changes, combined for both UML Schema -- Add attributes as per XSD above/spec table changes below Specification text: -- Figure 8.18 Correlation Class diagram Show the following added attributes in their compartments: CorrelationKey::name CorrelationProperty::name CorrelationProperty::type -- Table 8.32 CorrelationKey model associations Add the following row: name[0..1] | String | Specifies the name of the correlation key -- Table 8.33 CorrelationProperty model associations Add the following rows: name[0..1] | String | Specifies the name of the correlation property type[0..1]='String' | Element | Specifies the type of the correlation property |
| Comment by Matthias Kloppmann (IBM) [ 10/Feb/10 11:37 AM ] |
|
The last line should read
type[0..1]='String' | ItemDefinition | Specifies the type of the correlation property (the analogy from ResourceParameter lead me onto a wrong track, will open another issue to fix ResourceParameter::type) |
| Comment by Stephen White [ 17/Feb/10 05:24 PM ] |
| New Proposed Resolution |
[BPMNFTF-396] [OMG 14684] Merge Conversation and Collaboration
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-548 ##Original Info: (Severity: Critical - Nature: Revision) Conversation and Collaboration currently differ because Conversation messages can grouped, and Conversation can be reused. Since these capabilities are useful on collaboration, it would be simpler for users and implementers to merge these diagrams. Then there would be two interactions diagrams, one highlighting communication between participants (collaboration/conversation) and one highlighting the sequence of message flow (Choreography). This would be easier to explain and reduce the terminology complexity of the "three C models". -------------------- Proposal ---------- 2009-12-08 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for OMG 14641 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 16/Nov/09 03:44 PM ] |
| We will submit this issue directly to the OMG, which will come back to the FTF JIRA. Thus, we can close this issue. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-395] [OMG 14702] Beta 1: Section 17 BPMN Example: Include full BPMN example for this section
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-528 ##Original Info: (Severity: Critical - Nature: Enhancement) Section 17 will be temporarily removed until the BPMN example is added. The section should have a full example with diagrams, XML, and supporting text. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 11/Mar/10 03:18 AM ] |
| Non-normative text is not critical, hence we lower the priority. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 03:21 AM ] |
| Proposed resolution: Defer to the RTF, as this is non-normative. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 04:31 AM ] |
| New proposed resolution |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 12:59 PM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
[BPMNFTF-394] [OMG 14697] Service Task => Operation Task
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-535 ##Original Info: (Severity: Significant - Nature: Revision) Since the term "service" isn't used anymore in the interface and operation model, it would be better if ServiceTask were renamed, perhaps to OperationTask. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 28/May/09 05:57 PM ] |
| Actually I was just about to open an issue, suggesting we rename "Interface" to "Service Interface", given that "Interface" is generally an overloaded term. |
| Comment by Conrad Bock (NIST) [ 29/May/09 08:15 AM ] |
|
True, although I think it's less overloaded than "service", which has a
very different business meaning than in software. I thought "operation" was more neutral, and it's what is actually invoked by a Service Task (see the operationRef attribute on ServiceTask). |
| Comment by Gary Brown [ 27/Jan/10 03:56 AM ] |
|
But it might be better to name the task after what it does, i.e. "InvokeTask".
|
| Comment by Suzette Samoojh (IBM) [ 27/Jan/10 09:55 AM ] |
|
We need a term that has some business meaning.
I actually believe that Service Task is a reasonable choice. The business is using an external service, that just happens to have a well-defined interface. OperationTask is too techie IMO and a little obscure. InvokeTask is better, but still techie .... what business layperson knows what 'invoke' means. My vote is to remain with the established 'Service Task' term. |
| Comment by Bernd Ruecker (camunda) [ 27/Jan/10 10:01 AM ] |
|
I think ServiceTask is a very good choice and should stay like that, since it relates to services in the SOA world. It could boil down to services, web services, Java operations, whatever...
In the process modell Service Task is IMHO a good choice and pretty intuitive based on our experiences in the trainings, even for business people. Changing it would cause more confusion than it solves. So my vote is to keep Service Task, as Suzette already pointed out as well. |
| Comment by Conrad Bock (NIST) [ 27/Jan/10 10:50 AM ] |
|
Suzette, Bernd,
A business service is much more complicated than an operation call, we have interaction models for business level services. I don't think we should hide a software-level capability (invoking an operation) behind a business level name. OperationTask being techie is good, it reflects that the capability is actually techie. Business level users won't get the wrong idea from it, and technical people will still understand it. Conrad |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:22 PM ] |
|
Conrad,
I have to disagree. Business users won't understand OperationTask. This is an established term. I see no evidence that my business users get the wrong idea from it. I agree completely with Bernd. Changing it will cause more confusion than it solves. |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 10:29 AM ] |
|
Suzette,
Agreed business users will not understand OperationTask and I think that's a good thing. A task that invokes a single operation (which is all this one does) is too low level for business users to be concerned with. A typical "service" in the business sense is usually a complex interaction between organizations, which is better modeled with the interaction diagram. Changing ServiceTask to OperationTask will avoid confusion for business user who expect the term "service" to mean something much more complicated than the invocation of an operation. They won't know what invoking an operation means, and that's fine, this task is for the software-oriented users, who willunderstand it. Conrad |
| Comment by Tammo van Lessen [ 10/Feb/10 10:52 AM ] |
| I agree with Conrad. In addition, like Bernd said, a Service can be anything, but it does not necessarily have to follow the RPC paradigm. If I'm not mistaken, the Service Task is a special task for performing a request/response interaction with a partner (like the BPEL invoke), which is more a technical restriction than a business requirement. Since such req/resp patterns are heavily influenced by the semantics of traditional programming languages (operations that take some input and produce some output), I also think that the term OperationTask is more precise and less confusing than ServiceTask, as it invokes an operation and not a service with a potentially complex behavioral interface. |
| Comment by Suzette Samoojh (IBM) [ 10/Feb/10 11:06 AM ] |
|
The reality is that business people do currently use the Service Task. I know my business users do.
Also, consider the fact that the Service Task is in the Descriptive set for the proposed conformance levels. Which I see as further independent evidence that business people want to use it. So we should not make changes that would reduce the understandable of a construct to the audience that is already using it. |
| Comment by Matthias Kloppmann (IBM) [ 10/Feb/10 11:07 AM ] |
|
Yet another one agreeing with leaving it as is, at ServiceTask.
Albeit with another reason: It has been called ServiceTask since 1.1, that apparently hasn't caused too much confusion, and everyone is used to it now. Don't touch a running system ... :-) |
| Comment by Ivana Trickovic [ 10/Feb/10 11:16 AM ] |
| Agree to leave as it is. |
| Comment by Tammo van Lessen [ 10/Feb/10 11:17 AM ] |
| Agreed, here is my +1 for leaving it as it is in favor of backward compatibility. |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 11:36 AM ] |
|
Suzette,
> The reality is that business people do currently use the Service > Task. I know my business users do. > So we should not make changes that would reduce the understandable of > a construct to the audience that is already using it. The question is how tney're using it. For example, they might be using it with the intention of capturing a complex interaction, and don't get far enough into it to realize they can't. Or they could be using it for something like GetStockQuote, but that's not typical as a "business service". > Also, consider the fact that the Service Task is in the Descriptive > set for the proposed conformance levels. Which I see as further > independent evidence that business people want to use it. Sorry, what is the Descriptive set for the proposed conformance levels? In any case, these sets could be incorrect, presumably. Conrad |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 11:46 AM ] |
|
Matthias,
> Albeit with another reason: It has been called ServiceTask since 1.1, > that apparently hasn't caused too much confusion, and everyone is > used to it now. > Don't touch a running system ... :-) Not sure if there's a lack of confusion, but if there is, it could be due to local agreements on its meaning, rather than standard usage. The only way "service" appears to be used in spec is informally for web services (an incorrectly in ServiceInterface, etc), so I don't think this is a business level term as currently documented. Since software people will understand the term "operation" just as well, we can use that, rather than inadvertantly draw business users into an area that isn't what they intend. Conrad |
| Comment by Stephen White [ 11/Feb/10 01:15 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
Operation Task instead of Service Task? No consensus yet Service in a sense of Web service only? Should be use in a broad sense. Only in execution will the narrow meaning come into play. Could be a desktop application Operation could be used if needed Close? Extensible Need more text explanation. Need more complex services? There will be more offline discussions |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 08:59 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 07/Apr/10 10:38 AM ] |
|
-----------Proposal----------------Apr 7, 2010---------------------------
##Proposed Resolution: Closed, No Change Business modelers will usually take the term "service" in the business sense, rather than in the operation invocation sense of WSDL or UML, which is the current meaning of ServiceTask. However, implementations are too far along to change the name at this point. |
[BPMNFTF-393] [OMG 14696] Lanes and Sequence Flow
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Meera Srinivasan (Oracle) |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-536 ##Original Info: (Severity: Minor - Nature: Revision) As per the current spec, a Lane references FlowElements. But FlowElements include SequenceFlow, which introduces issues given that SequenceFlow can span Lanes (e.g. the source is in one Lane while the target is in another). Recommendation: The spec text should indicate that SequenceFlow are not included in the list of FlowElements referenced by a Lane. Tools are then responsible for presenting and laying out the SequenceFlow appropriately, based on its source and targets. ##Proposed Resolution: Fixed Lanes will reference FlowNodes, which exclude SequenceFlows (only activities, events and gateways are FlowNodes). We will change the semantic metamodel to reflect this change. a) in Figure 10.122 - The Lane class diagram , replace FlowElement with FlowNode b) below Figure 10.122, replace Flow Element with FlowNodes in these sentences: - "Each LaneSet and its Lanes can partition the Flow Elements in a different way." - "a tool can use to determine the list of Flow Elements to be partitioned into this Lane" c) in Table 10.128 - Lane attributes and model associations Replace flowElementRefs with flowNodeRefs, and FlowElement with FlowNode d) in Table 10.132 - Lane XML Schema Replace flowElementRef with flowNodeRef in this snippet <xsd:sequence> <xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOccurs="1"/> <xsd:element name="flowElementRef" type="xsd:IDREF" minOccurs="0" maxOccurs=" unbounded"/> |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 06:17 PM ] |
| Updated recommendation: The Lane should reference FlowNodes, not FlowElements. This will effectively remove SequenceFlow from the list, given SequenceFlow is a FlowElement but not a FlowNode. |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 06:59 AM ] |
|
proposalScheduledForBallot10
Meera is helping with these issues |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 10:13 AM ] |
|
The Lane should reference FlowNodes, not FlowElements. This will effectively remove SequenceFlow from the list, given SequenceFlow is a FlowElement but not a FlowNode.
Following places need to be updated to reflect this: (1) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 285 Original Text : Each LaneSet and its Lanes can partition the Flow Elements in a different way. Replacement Text : Each LaneSet and its Lanes can partition the Flow Nodes in a different way. (2) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 285 - Fig 10.122 - The Lane class diagram The diagram should be modified. Replace "FlowElement" with "FlowNode". |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 10:14 AM ] |
|
(3) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 285 Original Text: The Lane can define a partition element which specifies the value and element type, a tool can use to determine the list of Flow Elements to be partitioned into this Lane Replacement Text: The Lane can define a partition element which specifies the value and element type, a tool can use to determine the list of Flow Nodes to be partitioned into this Lane |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 10:19 AM ] |
|
(4) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 290 Table 10.132 - Lane XML Schema Original Text: <xsd:sequence> <xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOccurs="1"/> <xsd:element name="flowElementRef" type="xsd:IDREF" minOccurs="0" maxOccurs=" unbounded"/> Replacement Text: <xsd:sequence> <xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOccurs="1"/> <xsd:element name="flowElementRef" type="xsd:IDREF" minOccurs="0" maxOccurs=" unbounded"/> |
| Comment by Stephen White [ 29/Mar/10 04:32 PM ] |
| I assume that in the 4th change that "flowElementRef" should be "flowNodeRef" |
| Comment by Falko Menge [ 09/Jun/10 06:08 AM ] |
|
spec-May24-review
Table 2.1 and Table 10.19 still contain 'flowElementRef' elements. Proposal: Replace 'flowElementRef' with 'flowNodeRef' in Table 2.1 and Table 10.19. |
| Comment by Stephen White [ 11/Jun/10 06:30 PM ] |
| completed fix for spec-May24-review comment |
[BPMNFTF-392] [OMG 14700] XSD: mixed="true" is redundant in tFormalExpression element
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-532 ##Original Info: (Severity: Minor - Nature: Revision) Since it inherits from a base element with mixed content, it does not need to define itself as mixed. -------------------- Proposal ----------- 2010-01-04 --------------------------------- ##Proposed Resolution: Fixed Table 8.68, page 103 (133 pdf): remove attribute 'mixed="true"' in the tFormalExpression complex type definition. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 19/May/09 11:47 AM ] |
|
The 'mixed' setting does not need to be redeclared. It is transitively inherited. tExpression inherits it from tBaseElementWithMixedContent. tFormalExpression also (and thus it does not need to be redeclared there).
So there's a minor consistency issue (with tFormalExpression), but no technical issue to my knowledge. [Reducing the severity based on this information.] |
| Comment by Mariano Benitez (Oracle) [ 19/May/09 12:23 PM ] |
| suggest to defer but agree the resolution (remove mixed=True from tFormalExpression) |
| Comment by Antoine Toulme (Intalio) [ 02/Jan/10 04:12 PM ] |
| I agree with the resolution too. We actually hit this error when manipulating the semantic model, and I think it would be great to resolve this for beta 2. Is it possible ? |
| Comment by Antoine Toulme (Intalio) [ 04/Jan/10 06:49 PM ] |
|
-------------------- Proposal ----------- 2010-01-04 ---------------------------------
##Proposed Resolution: Fixed Table 8.68, page 103 (133 pdf): remove attribute 'mixed="true"' in the tFormalExpression complex type definition. ----------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 11/Jan/10 02:09 PM ] |
|
New Proposed Resolution: Fixed
Table 8.68, page 103 (133 pdf): remove attribute 'mixed="true"' in the tFormalExpression complex type definition |
[BPMNFTF-391] [OMG 14694] Typo in Terminate Event description
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-538 ##Original Info: (Severity: Minor - Nature: Revision) Section 10.4.5 Events Definitions pg. 250 of Beta 1 (pg 280 of 09-08-14.pdf). The section is for the Terminate Event, but it talks about the CancelEventDefinition rather than the TerminateEventDefinition. -------- New Proposed Resolution ---------- 2010-01-20 -------------------------------- ##Proposed Resolution: Fixed Change CancelEventDefinition with TerminateEventDefinition in the paragraph ----------------------------------------------------------------------------------------------------------- |
[BPMNFTF-390] [OMG 14698] Roles for Entities
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-534 ##Original Info: (Severity: Significant - Nature: Revision) There is no association between PartnerEntities and PartnerRoles, even though entities will play roles. The only link currently is through participant, requiring modification of a C models to link a role or entity, see http://www.osoa.org/jira/browse/BPMN-520. An association between partner entities and roles would enable collections of C models to be grouped by roles, with roles reused by entities. -----------Proposal----------------Apr 5, 2010--------------------------- ##Proposed Resolution: Defer This is deferred for more discussion in the RTF, in conjunction with better specification of partner roles, see BPMNFTF-349 [OMG 14661]. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:44 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:22 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Defer This is deferred for more discussion in the RTF, in conjunction with better specification of partner roles, see BPMNFTF-349 [OMG 14661]. |
[BPMNFTF-389] [OMG 14699] Multiple PartnerEntities per Participant
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-533 ##Original Info: (Severity: Critical - Nature: Revision) Sections 8.3.15, 9.2, and 9.5 Collaborations and other C models might be in reusable libraries, but currently their participants cannot be linked to multiple entities, and cannot be linked with modifying the C model. For example, a collaboration might describe a contract that many entities can enter into. This contract might be in a library and not be modifiable. Entities should still be able to refer to participants in it to indicate they commit to the contract. This commitment is made jointly by multiple entities, each linked to their own participants. |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:00 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:33 AM ] |
| See comment http://www.osoa.org/jira/browse/BPMNFTF-335#action_16137. |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 12:31 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Fixed The associations from Participant to PartnerEntity and PartnerRole should be unidirectional from PartnerEntity and PartnerRole, rather than Participant, and have unbounded multiplicity on both ends. This enables modelers to assign entities and roles to interaction models in libraries without modifying the library. The resolution assumes the resolution of In the Collaborations chapter, Participants section, figure The Participant Class Diagram, on the partnerRoleRef and partnerEntityRef associations from Participant: - Change the 0..1 multiplicities to *. - Insert a "/" just before the association end names (but not part of the names). - Reverse the navigation direction of the associations (leaving the association end names where they are). - Name the unamed association ends "participantRef". In the Collaborations chapter, Participants section, in the table Participant attributes and model associations: - In the partnerRoleRef row, right column, at the end, add the sentence, "This attribute is derived from the participantRefs of Partner Roles." - In the partnerEntityRef row, right column, at the end, add the sentence, "This attribute is derived from the participantRefs of Entity Roles." In the Collaborations chapter, Participants section, PartnerEntity subsection, in the table PartnerEntity attributes, add a row at the end: - participantRef [0..*] Specifies how the Partner Entity participates in collaborations and choreographies. In the Collaborations chapter, Participants section, PartnerRole subsection, in the table PartnerEntity attributes, add a row at the end: - participantRef [0..*] Specifies how the Partner Role participates in collaborations and choreographies. In the Collaborations chapter, Collaboration Package XML Schemas section, in table Participant XML schema, remove: <xsd:attribute name="partnerRoleRef" type="xsd:QName" use="optional"/> <xsd:attribute name="partnerEntityRef" type="xsd:QName" use="optional"/> |
| Comment by Ivana Trickovic [ 07/Jun/10 06:29 AM ] |
|
spec-May24-review
According to the issue resolution, for the partnerRoleRef and partnerEntityRef associations from Participant, the multiplicity changed from 0..1 to *. This should be changed in the specification text. |
| Comment by Stephen White [ 10/Jun/10 04:56 PM ] |
| completed fix for spec-May24-review comment |
[BPMNFTF-388] [OMG 14703] CorrelationSubscription - Description & use-cases
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-526 ##Original Info: (Severity: Significant - Nature: Revision) Section 8.3.3 Correlation - Sub-Section Context-based Correlation The Correlation Subscription concepts in the spec are difficult to follow and understand. We need improved explanations in the spec, with descriptions of when and how someone would use this, and the motivations behind it. ##Proposed Resolution: Fixed 1. Add the following introductory paragraph motivating the need for correlation: Business processes typically may run for days or even months, requiring asynchronous communication via messages. Also, many instances of a particular business process will typically run in parallel, e.g., many instances of an order process, each representing a particular order. *Correlation* is used to associate a particular message to an ongoing conversation between too particular business process instances. BPMN allows using existing message data for correlation purposes, e.g., for the order process, a particular instance can be identified by means of its order ID and/or customer ID, rather than requiring the introduction of technical correlation data. 2. Add a footnote to the next paragraph clarifying that it also refers to message events -- here is the original paragraph with the suggested footnote in *** ***: The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task***All references to Send or Receive Tasks in this section also include message catch or throw events -- they behave identically with respect to correlation*** in a Conversation, a mechanism BPMN refers to as instance routing. It is a particular useful concept where there is no infrastructure support for instance routing. Note that this association can be viewed at multiple levels, namely the Conversation, Choreography, and Process level. However, the actual correlation happens during runtime (e.g., at the Process level). Correlations describe a set of predicates on a Message (generally on the application payload) that need to be satisfied in order for that Message to be associated to a distinct Send Task or Receive Task. By the same token, each Send Task and each Receive Task participates in one or many Conversations. Furthermore, it identifies the Message it sends or receives and thereby establishes the relationship to one (or many) CorrelationKeys. |
| Comments |
| Comment by Stephen White [ 24/Jul/09 01:05 PM ] |
| Yes, Section 8.3.3 (V0.9.14) needs a complete overhaul. |
| Comment by Stephen White [ 17/Dec/09 08:15 PM ] |
| Assigned to both Process Orchestration and Interaction since the issue will deal with process instances and conversations. |
| Comment by Ivana Trickovic [ 10/Mar/10 08:02 AM ] |
|
As per March F2F Meeting:
- Depending on the size it may be consider as RTF issue. Matthis will come up with a proposal what to do. |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:22 AM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:18 AM ] |
|
Proposal:
1. Add the following introductory paragraph motivating the need for correlation: Business processes typically may run for days or even months, requiring asynchronous communication via messages. Also, many instances of a particular business process will typically run in parallel, e.g., many instances of an order process, each representing a particular order. *Correlation* is used to associate a particular message to an ongoing conversation between too particular business process instances. BPMN allows using existing message data for correlation purposes, e.g., for the order process, a particular instance can be identified by means of its order ID and/or customer ID, rather than requiring the introduction of technical correlation data. 2. Add a footnote to the next paragraph clarifying that it also refers to message events -- here is the original paragraph with the suggested footnote in *** ***: The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task***All references to Send or Receive Tasks in this section also include message catch or throw events -- they behave identically with respect to correlation*** in a Conversation, a mechanism BPMN refers to as instance routing. It is a particular useful concept where there is no infrastructure support for instance routing. Note that this association can be viewed at multiple levels, namely the Conversation, Choreography, and Process level. However, the actual correlation happens during runtime (e.g., at the Process level). Correlations describe a set of predicates on a Message (generally on the application payload) that need to be satisfied in order for that Message to be associated to a distinct Send Task or Receive Task. By the same token, each Send Task and each Receive Task participates in one or many Conversations. Furthermore, it identifies the Message it sends or receives and thereby establishes the relationship to one (or many) CorrelationKeys. |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:18 AM ] |
| newProposedResolution |
[BPMNFTF-387] [OMG 14701] XML-Schema type for 'from' and 'to' elements in Data Assignment must not be abstract
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Ralf Mueller | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Oracle (Ralf Müller, ralf.mueller@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-531 ##Original Info: (Severity: Significant - Nature: Revision) The XML-Schema type for elements "from" and "to" in complex type "tAssignment" is "tBaseElementWithMixedContent". However this type is declared abstract and forces to specify a xsi:type attribute for elements "from" and "to". The proposal is to use a non-abstract XML-schema type for "from" and "to" elements. A good candidate would be "tExpression" which is a non-abstract extension of "tBaseElementWithMixedContent": <xsd:complexType name="tAssignment"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element name="from" type="tExpression" minOccurs="1" maxOccurs="1"/> <xsd:element name="to" type="tExpression" minOccurs="1" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="language" type="xsd:anyURI"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> ##Proposed Resolution: Fixed 1. Spec table 10.58 a. Remove attribute "language". b. Modify attributes "from" and "to". Make both of type "Expression". Remove "body of the" from the attribute descriptions. 2. XSD a. Remove attribute "language". b. Change the type of the "from" and "to" attributes in tAssignment to tExpression. c. Modify XSD snippet in Table 10.63 to match. 3. UML metamodel a. Remove attribute "language". b. Change the "from" and "to" attributes in the Assignment class to be of type Expression. c. Replace Figure 10.61. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:30 PM ] |
| Proposal: Change the from/to elements to be of type tExpression, as recommended in the original issue description. |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:03 PM ] |
| proposalScheduledForBallot11 |
| Comment by Mariano Benitez (Oracle) [ 29/Mar/10 09:14 AM ] |
|
Since both "from" and "to" will be expressions, there is no need for the "language" attribute in Assignment, so it should be removed too.
This comes from |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 12:50 PM ] |
|
------------------------------------------------------------------------------------
Proposed resolution: Fixed 1. Spec table 10.58 a. Remove attribute "language". b. Modify attributes "from" and "to". Make both of type "Expression". Remove "body of the" from the attribute descriptions. 2. XSD a. Remove attribute "language". b. Change the type of the "from" and "to" attributes in tAssignment to tExpression. c. Modify XSD snippet in Table 10.63 to match. 3. UML metamodel a. Remove attribute "language". b. Change the "from" and "to" attributes in the Assignment class to be of type Expression. c. Replace Figure 10.61. |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 12:22 PM ] |
|
Spec-Draft3-review
Table 10.69 - Assignment XML schema the language attribute is not removed from snippet |
| Comment by Suzette Samoojh (IBM) [ 11/May/10 12:30 PM ] |
|
Looks like the entire snippet is incorrect in the spec. Needs to be replaced with content from the XSD.
The XSD has the correct content. <xsd:element name="assignment" type="tAssignment" /> <xsd:complexType name="tAssignment"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element name="from" type="tExpression" minOccurs="1" maxOccurs="1"/> <xsd:element name="to" type="tExpression" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comment by Ivana Trickovic [ 17/May/10 03:32 PM ] |
| As per the meeting of May 17th: Agreed that this needs to b fixed |
| Comment by Stephen White [ 19/May/10 05:14 PM ] |
| Done |
[BPMNFTF-386] [OMG 14695] Grouping message flow in Collaboration
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-537 ##Original Info: (Severity: Critical - Nature: Revision) Message flow can be grouped in Choreography and Conversation, and should be in Collaboration also. For example, a collaboration participant might have a process with a call activity that send/receives many messages. The modeler should be able to show these as a single line between the activity and the other participant, as in a conversation. otherwise, the modeler can only show the most detailed view of the interaction, with every lowest level message flow in the diagram. ##Proposed Resolution: Duplicate The resolution for Issue 14564 will resolve this issue |
| Comments |
| Comment by Stephen White [ 18/Mar/10 08:28 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 22/Mar/10 07:44 PM ] |
| Reduced Priority from Critical to Major |
[BPMNFTF-385] [OMG 14682] Section 11 Conversation: Fix Conversation figures for proper notation for Pools
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-551 ##Original Info: (Severity: Significant - Nature: Enhancement) The figures of the Conversation show the Pools without the proper notation (as defined in BPMN-305). These should be fixed. There are also two figures in the Collaboration chapter that also need fixing. -------------------- Proposal ----------- 2009-12-17 --------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate of ------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 13/Sep/09 11:14 PM ] |
| Version number removed from summary so that it will apply to the Beta 1 spec |
| Comment by Stephen White [ 17/Dec/09 08:22 PM ] |
|
The resolution to this issue was defined and applied by JIRA Issue 194 (OMG Issue 14250)
-------------------- Proposal ----------- 2009-12-17 --------------------------------- Close this issue as a duplicate. ------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-384] [OMG 14685] CorrelationSubscription Ownership
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-general.doc
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-547 ##Original Info: (Severity: Significant - Nature: Revision) Figure 8-18 (The Correlation Class Diagram) shows only one-way references away from CorrelationSubscription. What owns CorrelationPropertyBindings? Table 8-35 (CorrelationSubscription model associations) says it's a BaseElement, and that it has a Process attribute. The subsection on Context-based Correlation in Section 8.3.3 (Correlation) implies it is owned by Process. ##Proposed Resolution: Fixed > Section 8.3.3 Correlation Figure 8.18 - The Correlation Class Diagram Change metamodel Original CorrelationSubscription is contained in Common package but is not contained by any concept Proposal (in accordance with Table 8.35 - CorrelationSubscription model associations) 1 Process contains n CorrelationSubscriptions. Each CorrelationSubscription is contained by exactly 1 Process. Add association from Process to CorrelationSubscription. > Section 10 Process Figure 10.3 - Process Details class diagram Change metamodel Original Process class has no association to CorrelationSubscription class. Proposal Add containment Process CorrelationSubscription: 1 Process contains n CorrelationSubscriptions. Table 10.1 - Process Attributes & Model Associations Append row: subscriptions: CorrelationSubscription [0..*] Original N/A Proposal Attribute Name subscriptions: CorrelationSubscription [0..*] Description/Usage Correlation Subscriptions are a feature of context-based correlation (cf. section 8.3.3). Subscriptions are used to correlate incoming messages against data in the Process context. A Process may several subscriptions. |
| Comments |
| Comment by Stephen White [ 18/Feb/10 11:23 AM ] |
|
-------------- Proposal ----------- 2010-02-16 -----------------------------------
Close with no changes. Subscription is owned by a Process. This is correctly reflected in the metamodel and specification text. --------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 03/Mar/10 06:34 PM ] |
|
--------------------------- Discussed During Conference Call on 2010-03-03 --------------------------------
If Correlation Subscription is owned by Process, then it should show it Table 10.1 and shown in a diagram Can't close yet. Check MM. and we need to update table and figure. |
| Comment by Ivana Trickovic [ 10/Mar/10 08:39 AM ] |
|
As per March F2F Meeting:
- Correlation Subscription is contained in Common package, but has no other containment. This must be corrected in the MM and the specification. We need a concrete example to support the proposal. |
| Comment by Ivana Trickovic [ 22/Mar/10 06:05 PM ] |
| proposalScheduledForBallot11 |
| Comment by Karsten Ploesser (SAP) [ 13/Apr/10 02:36 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 13/Apr/10 02:39 AM ] |
|
Issue resolution proposal
> Section 8.3.3 Correlation Figure 8.18 - The Correlation Class Diagram Change metamodel Original CorrelationSubscription is contained in Common package but is not contained by any concept Proposal (in accordance with Table 8.35 - CorrelationSubscription model associations) 1 Process contains n CorrelationSubscriptions. Each CorrelationSubscription is contained by exactly 1 Process. Add association from Process to CorrelationSubscription. > Section 10 Process Figure 10.3 - Process Details class diagram Change metamodel Original Process class has no association to CorrelationSubscription class. Proposal Add containment Process CorrelationSubscription: 1 Process contains n CorrelationSubscriptions. Table 10.1 - Process Attributes & Model Associations Append row: subscriptions: CorrelationSubscription [0..*] Original N/A Proposal Attribute Name subscriptions: CorrelationSubscription [0..*] Description/Usage Correlation Subscriptions are a feature of context-based correlation (cf. section 8.3.3). Subscriptions are used to correlate incoming messages against data in the Process context. A Process may several subscriptions. |
| Comment by Karsten Ploesser (SAP) [ 13/Apr/10 02:40 AM ] |
| New Proposed Resolution |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:40 AM ] |
|
Bugfix required
Table 8.34 - CorrelationSubscription model associations > Remove first row (process:Process) |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:40 AM ] |
| Spec-Draft3-review |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:47 AM ] |
|
Bugfix required
Table 8.34 - CorrelationSubscription model associations > DELETE first row (process:Process) Figure 10.29- The Sub-Process class diagram Table 10.20 - Sub-Process attributes Table 10.48 - SubProcess XML schema > ADD attribute correlationSubscriptions:CorrelationSubscription [0..*] to class Sub-Process |
| Comment by Karsten Ploesser (SAP) [ 14/May/10 01:47 AM ] |
| Spec-Draft3-review |
| Comment by Ivana Trickovic [ 17/May/10 03:32 PM ] |
|
As per the meeting of May 17th:
Agreed that the first part needs to be fixed as there is a mismatch between the specification and the MM. First row to be deleted. The second part is a new request and a new issue shall be posted (probably relevant for the upcoming RTF activity). |
| Comment by Stephen White [ 18/May/10 05:10 PM ] |
| Done |
[BPMNFTF-383] [OMG 14683] Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | WS-BPEL Mapping |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-550 ##Original Info: (Severity: Minor - Nature: Revision) Page 453. The first sentance of the section states: "The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):" However, the table is not there. ----------------- Proposal ------------------ 2010-02-16 --------------------------------- ##Proposed Resolution: Defer Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF ---------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 01:34 PM ] |
| Even if issues related to WS-BPEL mapping can be covered by the Process Orchestration sub-group, we should keep them separated for clarity |
| Comment by Stephen White [ 16/Feb/10 05:36 PM ] |
|
----------------- Proposal ------------------ 2010-02-16 ---------------------------------
Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF ---------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 16/Feb/10 05:36 PM ] |
| New Proposed Resolution |
[BPMNFTF-382] [OMG 14688] MessageFlowRefs missing from Conversation metamodel diagram
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-544 ##Original Info: (Severity: Significant - Nature: Revision) MessageFlowRefs missing from Conversation metamodel diagram (compare to Conversation attributes table). ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 16/Feb/10 06:21 PM ] |
|
MessageFlowRefs should not be in this table since it is an attribute of Interaction Specification, not Conversation.
Thus, the row in the table should be removed. But this issue will no longer be valid if there is a resolution for Issue 334. |
| Comment by Stephen White [ 22/Mar/10 06:39 PM ] |
| New Proposed Resolution |
[BPMNFTF-381] [OMG 14692] Need to revisit and test the process example in the spec (Figure 7-8)
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Critical |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Figure 7-8 Beta 1 Draft 1.png
Figure 7-8 Proposal 2010-03-26.png
Figure 7-8 Proposal 2010-03-26.vsd
Figure 7-8 Proposal 2010-04-01.png
Figure 7-8 Proposal 2010-04-01.vsd
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-540 ##Original Info: (Severity: Critical - Nature: Revision) Need to revisit and test the process example in the spec (Figure 7-8). I'm not convinced this example 'works'. Some immediate concerns: - Process Parts does not have any data output. So I'm not sure what the conditional sequence flow out of it would evaluate against. - The 'artifact extensions' appear to be used like data-aware elements, but they're not really. I'd suggest we validate the example further. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 08:40 AM ] |
|
As per March F2F Meeting:
- We agreed either fix the issue or remove the example. |
| Comment by Ivana Trickovic [ 22/Mar/10 11:40 AM ] |
| proposalScheduledForBallot10 |
| Comment by Falko Menge [ 26/Mar/10 05:34 PM ] |
| For better comparison, screenshots of the original diagram (Figure 7-8 Beta 1 Draft 1.png) and the proposal (Figure 7-8 Proposal 2010-03-26.png) have been attached. |
| Comment by Suzette Samoojh (IBM) [ 29/Mar/10 03:04 PM ] |
| Are the artifact extensions (Parts, Part) really needed? I'd recommend removing them. I find them rather confusing myself. Their names make them sound like Data Objects, and so I could see someone thinking they are Data Objects. |
| Comment by Stephen White [ 31/Mar/10 10:56 PM ] |
|
------------- Conference call on 2010-03-31 ---------------------
We agreed to adjust the proposal to explicitly state that Figure 7.8 will be replaced. We also agreed that the figure should be further updated to remove the Artifact extensions. |
| Comment by Falko Menge [ 05/Apr/10 03:13 AM ] |
| The attachment 'Figure 7-8 Proposal 2010-04-01.vsd' contains all changes made in 'Figure 7-8 Proposal 2010-03-26.vsd'. However, all remaining artifact extensions have also been removed. |
| Comment by Falko Menge [ 05/Apr/10 03:24 AM ] |
|
-----Proposal---------------- 04/01/2010 -------------------------
##Proposed Resolution: Fixed Replace Figure 7.8 with the figure shown here: http://www.osoa.org/jira/secure/attachment/10668/Figure+7-8+Proposal+2010-04-01.png To address the first concern, a data output has been introduced to the sub-process 'Procure Parts', which the conditional sequence flow can now evaluate against. The artifact extension 'Order Folder' and the associations connected to it have been substituted by two data associations from the data objects 'Assemblies (1..n)' and 'Invoice' to the human task 'Send Assemblies & Invoice to Customer'. This usage of an artifact extension is possible, but miss-leading, because it suggests that the artifact is a data object connected via data associations. However, a data association can only connect a data object with an activity or event, but not data objects with each other. See also page 198 (230): 'The DataAssociation class is a BaseElement contained by an Activity or Event, [...]' All remaining artifact extensions have also been removed. Besides this, we made some minor layout improvements that did not change the semantics. |
| Comment by Falko Menge [ 05/Apr/10 03:27 AM ] |
| New Proposed Resolution |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:59 AM ] |
| Per the FTF Call on 5/4, Falko's latest proposal is correct, which will be included in Ballot 10. |
| Comment by Falko Menge [ 14/May/10 08:15 PM ] |
|
Spec-Draft3-review
The resolution has been applied correctly, but the image quality is rather poor. Would be possible to use vector graphics instead of rasterized 'screenshots' for figures like this? |
| Comment by Ivana Trickovic [ 17/May/10 03:27 PM ] |
| As per the meeting of May 17th: Agreed that this needs to b fixed |
| Comment by Stephen White [ 18/May/10 05:04 PM ] |
| I managed to get a copy of the figure in a metafile, but not sure how much better the quality will be. |
[BPMNFTF-380] [OMG 14689] Conversation/Communication switch
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-543 ##Original Info: (Severity: Significant - Nature: Revision) A number of places in the text use the word "conversation" that should be "communication", for example Figure 11-1 and in Section 11 (eg, A Conversation is set of Message exchanges (Message Flow) that share the same correlation). -----------Proposal----------------Apr 5, 2010--------------------------- ##Proposed Resolution: Duplicate This is addressed by the resolution of |
| Comments |
| Comment by Stephen White [ 18/Mar/10 04:34 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:24 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Fixed This is addressed by the resolution of |
[BPMNFTF-379] [OMG 14687] Semantic metamodel => Abstract syntax
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-545 ##Original Info: (Severity: Significant - Nature: Revision) The term "semantics" is used in execution to refer to how a model is translated to runtime (or business) behavior, which is the technical meaning of the word. Metamodels, on the other hand, are a kind of syntax that omits some details of the pictures appearing on the screen. Would be better to use the term "Abstract syntax" instead of "Semantic metamodel" when it's necessary to distinguish it from the diagram metamodel. |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:01 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:35 AM ] |
| See comment http://www.osoa.org/jira/browse/BPMNFTF-335#action_16137. This is not an interaction issue, I just missed it in assigning issues to myself, sorry for the confusion. |
| Comment by Mariano Benitez (Oracle) [ 07/Apr/10 07:41 AM ] |
| Conrad, can you please include in your resolution the complete list of occurrences? The FTF report requires that. |
| Comment by Conrad Bock (NIST) [ 13/Apr/10 01:46 PM ] |
|
-----------Proposal----------------Apr 13, 2010---------------------------
##Proposed Resolution: Fixed Metamodels are an abstract form of syntax that omits some aspects of visual (concrete) syntax. Semantics is about how a business behaves given a model defined with the syntax. Above Figure 8.2 (Class diagram showing the core packages), first bullet, replace "semantic modeling" with "modeling". Section 8.2 (Foundation), first sentence, replace "semantic model" with "abstract syntax model". Section A.1 (Changes from BPMN, v1.2), third paragraph, second bullet, replace "semantic model" with "abstract syntax model". Section 8.1 (Infrastructure), first sentence, replace "semantic models" with "abstract syntax models". |
[BPMNFTF-378] [OMG 14686] Exclusive gateway Choreography rules too restrictive, only sender needed
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-546 ##Original Info: (Severity: Significant - Nature: Revision) Decisions are prevented from being used Choreographies if not all participants have access to the information on which the decision is made. But if the activities following the gateway are all sent by the same participant, only that participant needs to know how the decision is made. Using an event-based gateway in this case is confusing, since there is no waiting for events to proceed to the activities following it. Some sided email below about this. Steve, > The Gateway would most likely be Event based. The Buyer is > probably not going to be aware of the data that would be > used to make the decision, particularly a change order. > Thus, the Buyer is just going to be waiting for one of the > three responses. Makes sense for the buyer, but this isn't a model of the buyer (and the Seller is making a regular decision, why isn't that shown?). It's also odd to see an event-based gateway in a choreography since choreography can't don't wait for events, the participants do. The figure looks right according to the spec, but I think the spec is too restrictive on regular decisions in choreogrpahies. Conrad Steve, > The Seller is making a regular decision internally, but the > rationale (i.e., data) used to make the decision is private > for the Seller. A Choreography can only use Exclusive > Gateways if the data used for them is public. I understand that's the rule, but I'm not sure it make sense. In this case, the activities following the gateway are all initiated by the Seller. The rule should be that the seller has access to the decision data. > The Buyer does not know ahead of time, what the > results of the decision will be since the Buyer has not seen the > Seller's internal data. And that's fine, because it isn't the Buyer who initiates any of the activities after the gateway. > All private Exclusive Gateways show up as Event Gateways in a > Choreography. This is too hard to explain, for example, who receives the event? The choreography itself can't received an event, and there's no indication that it's the Buyer (other than they Buyer is receiving in the activities after the gateway). For FTF discussion. :) Conrad |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:01 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:32 AM ] |
| See comment http://www.osoa.org/jira/browse/BPMNFTF-335#action_16137. |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 02:32 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Defer This requires decisions with no conditions in a choreography, which means the conditions are known privately to the sender of the activities after the exclusive gateway, but not modeled in the "public" choreography. This avoids event-based gateways in choreographies, which cannot respond to events. These "abstract" choreographies are possible, but requires more discussion in RTF in conjunction with BPMNFTF-347 [OMG 14663]. |
[BPMNFTF-377] [OMG 14693] Error class has no 'name' attribute
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Error Metamodel.jpg
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-539 ##Original Info: (Severity: Minor - Nature: Revision) For it to be usable, it needs a 'name' attribute. ------------------------ New Proposed Resolution ----------- 2010-01-26 ------------------------------------------------------ ##Proposed Resolution: Fixed (a) Table 8.43: Add a new attribute called "name", with description "The descriptive name of the error". (b) Table 8.64 (schema snippet): Update XSD snippet to add the 'name' attribute. <xsd:element name="error" type="tError" substitutionGroup="rootElement"/> <xsd:complexType name="tError"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> (c) Figure 8.20: Replace with http://www.osoa.org/jira/secure/attachment/10603/Error+Metamodel.jpg ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 05:33 PM ] |
|
-----Proposal---------------- 01/26/2010 -------------------------
Table 8.43: Add a new attribute called "name", with description "The descriptive name of the error". Table 8.64 (schema snippet): Update XSD snippet to add the 'name' attribute. <xsd:element name="error" type="tError" substitutionGroup="rootElement"/> <xsd:complexType name="tError"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> Figure 8.20: Replace with http://www.osoa.org/jira/secure/attachment/10603/Error+Metamodel.jpg |
[BPMNFTF-376] [OMG 14690] Choreography Subprocess => Subchoreography
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-542 ##Original Info: (Severity: Significant - Nature: Revision) To avoid confusion of Choreography with Process, and to be consistent with naming of analogous elements in Process, it seems like Choreography Subprocess should be renamed to Subchoreography. ---------------------- New Proposed Resolution -------- 2010-01-11 --------------------- ##Proposed Resolution: Fixed Change all occurrences of "Choreography Sub-Process" to "Sub-Choreography" ------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 11/Jan/10 07:19 PM ] |
|
----------------------- New Proposed Resolution -------- 2010-01-11 ---------------------
Change all occurrences of "Choreography Sub-Process" to "Sub-Choreography" ------------------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 12/Jan/10 09:13 PM ] |
| New Proposed Resolution: Fixed |
[BPMNFTF-375] [OMG 14691] Service Package => Interface Package
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Ivana Trickovic |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-541 ##Original Info: (Severity: Significant - Nature: Revision) Since the term "service" isn't used anymore in the interface and operation model, it would be better if the Service Package were renamed, perhaps to Interface Package. ##Proposed Resolution: Close; No Change The proposal is to close the issue with no changes to the specification. Concepts "interface" and "operation" are used to model services. There is no need to rename "Service Package" as term "service" is a "superordinate" concept. |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:35 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 26/Mar/10 07:26 AM ] |
|
------------------- Proposal ------------ 2010-03-26 -------------------------------------------------
##Proposed Resolution: Close; No Change The proposal is to close the issue with no changes to the specification. Concepts "interface" and "operation" are used to model services. There is no need to rename "Service Package" as term "service" is a "superordinate" concept. |
| Comment by Ivana Trickovic [ 26/Mar/10 07:26 AM ] |
| New Proposed Resolution |
[BPMNFTF-374] [OMG 14675] Beta 1: Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-558 ##Original Info: (Severity: Significant - Nature: Enhancement) From Mohamed Keshk (via email): In "Semantic.xmi" file, the only sub-classes of "MessageFlowNode" are: Task, Event, and Participant. While in pdf specs, page 122, first section entitled with "MessageFlowNode", first paragraph, the following is written: "Only the Pool/Participant, Activity, and Event elements can connect to Message Flow and thus, these elements are the only ones that are sub-classes of MessageFlowNode". ##Proposed Resolution: Close; No Change The elements listed in the schema are correct. If a Task or Event is contained within a Sub-Process that is collapsed, then the tool will be able to derived that the connection should be redirected to the boundary of the Sub-Process. Am I missing something here, or some changes should be made? |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:38 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-373] [OMG 14674] Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving.
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-559 ##Original Info: (Severity: Significant - Nature: Enhancement) The general description of Complex Gateways needs improving. An example or two would be good. |
| Comments |
| Comment by Stephen White [ 13/Sep/09 11:49 PM ] |
| The version number was removed from the summary so that it will apply to the Beta 1 spec |
| Comment by Stephen White [ 22/Mar/10 06:36 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:36 PM ] |
| Update the issue resolution to clarify that due to the size of the specification that FTF decided to create a separate non-normative document with examples. Therefore all issue requesting examples are deferred. |
| Comment by Ivana Trickovic [ 06/Apr/10 02:47 PM ] |
|
##Proposed Resolution: Defer
Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF/FTF. |
[BPMNFTF-372] [OMG 14676] Error vs ErrorCode & Escalation vs EscalationCode
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Error_MM.jpg
ErrorEventDefinition_MM.jpg
Escalation_MM.jpg
EscalationEventDefinition_MM.jpg
EventDefinitions_MM.jpg
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-557 ##Original Info: (Severity: Minor - Nature: Enhancement) The ErrorEventDefinition contains an errorCode and references an Error class. Wouldn't it make sense for errorCode to be moved into the Error class. I'd expect that all usages of that Error class would specify the same errorCode. Same pattern is there for Escalation. -----Proposal---------------- 02/02/2010 ------------------------- ##Proposed Resolution: Fixed (a) Insert new subsection, under 8.3, for Escalation. An Escalation identifies a business situation that a process may need to react to. Insert Figure http://www.osoa.org/jira/secure/attachment/10607/Escalation_MM.jpg The Escalation element inherits the attributes and model associations of Base Element through its relationship to RootElement. New table, with attributes name: The descriptive name of the escalation structureRef: An ItemDefinition that defines the payload of the escalation (b) Move the "errorCode" attribute from Table 10.89 to Table 8.43 (c) Move the "escalationCode" attribute from Table 10.90 to new table for Escalation (d) Replace Figure 8.20 with http://www.osoa.org/jira/secure/attachment/10605/Error_MM.jpg (e) Replace Figure 10.70 with http://www.osoa.org/jira/secure/attachment/10609/EventDefinitions_MM.jpg (f) Replace Figure 10.75 with http://www.osoa.org/jira/secure/attachment/10606/ErrorEventDefinition_MM.jpg (g) Replace Figure 10.77 with http://www.osoa.org/jira/secure/attachment/10608/EscalationEventDefinition_MM.jpg (h) Table 8.64 (schema snippet): Updated XSD snippet to add the errorCode attribute to tError <xsd:element name="error" type="tError" substitutionGroup="rootElement"/> <xsd:complexType name="tError"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> <xsd:attribute name="errorCode" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> (i) New table under 8.3.18, for the Escalation schema snippet <xsd:element name="escalation" type="tEscalation" substitutionGroup="rootElement"/> <xsd:complexType name="tEscalation"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> <xsd:attribute name="escalationCode" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> (j) Table 10.101: Updated XSD snippet to remove the errorCode attribute from tErrorEventDefinition <xsd:element name="errorEventDefinition" type="tErrorEventDefinition" substitutionGroup="eventDefinition"/> <xsd:complexType name="tErrorEventDefinition"> <xsd:complexContent> <xsd:extension base="tEventDefinition"> <xsd:attribute name="errorRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> (k) New table under 10.4.8, for the EscalationEventDefinition schema snippet <xsd:element name="escalationEventDefinition" type="tEscalationEventDefinition" substitutionGroup="eventDefinition"/> <xsd:complexType name="tEscalationEventDefinition"> <xsd:complexContent> <xsd:extension base="tEventDefinition"> <xsd:attribute name="escalationRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:05 PM ] |
| While putting together a proposal for this, I noticed that the spec is missing a section on Escalation. Given I prereq that section, I'll roll that resolution into my proposal. |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:21 PM ] |
|
-----Proposal---------------- 02/02/2010 -------------------------
Insert new subsection, under 8.3, for Escalation. An Escalation identifies a business situation that a process may need to react to. Insert Figure http://www.osoa.org/jira/secure/attachment/10607/Escalation_MM.jpg The Escalation element inherits the attributes and model associations of Base Element through its relationship to RootElement. New table, with attributes name: The descriptive name of the escalation structureRef: An ItemDefinition that defines the payload of the escalation Move the "errorCode" attribute from Table 10.89 to Table 8.43 Move the "escalationCode" attribute from Table 10.90 to new table for Escalation Replace Figure 8.20 with http://www.osoa.org/jira/secure/attachment/10605/Error_MM.jpg Replace Figure 10.70 with http://www.osoa.org/jira/secure/attachment/10609/EventDefinitions_MM.jpg Replace Figure 10.75 with http://www.osoa.org/jira/secure/attachment/10606/ErrorEventDefinition_MM.jpg Replace Figure 10.77 with http://www.osoa.org/jira/secure/attachment/10608/EscalationEventDefinition_MM.jpg Table 8.64 (schema snippet): Updated XSD snippet to add the errorCode attribute to tError <xsd:element name="error" type="tError" substitutionGroup="rootElement"/> <xsd:complexType name="tError"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> <xsd:attribute name="errorCode" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> New table under 8.3.18, for the Escalation schema snippet <xsd:element name="escalation" type="tEscalation" substitutionGroup="rootElement"/> <xsd:complexType name="tEscalation"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="structureRef" type="xsd:QName"/> <xsd:attribute name="escalationCode" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> Table 10.101: Updated XSD snippet to remove the errorCode attribute from tErrorEventDefinition <xsd:element name="errorEventDefinition" type="tErrorEventDefinition" substitutionGroup="eventDefinition"/> <xsd:complexType name="tErrorEventDefinition"> <xsd:complexContent> <xsd:extension base="tEventDefinition"> <xsd:attribute name="errorRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> New table under 10.4.8, for the EscalationEventDefinition schema snippet <xsd:element name="escalationEventDefinition" type="tEscalationEventDefinition" substitutionGroup="eventDefinition"/> <xsd:complexType name="tEscalationEventDefinition"> <xsd:complexContent> <xsd:extension base="tEventDefinition"> <xsd:attribute name="escalationRef" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
[BPMNFTF-371] [OMG 14681] Correlation Key & Correlation Properties are missing 'name' attributes
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-552 ##Original Info: (Severity: Significant - Nature: Revision) I'd think that CorrelationKey at a minimum needs a name. I'm not too sure that CorrelationProperty does, but give it is a RootElement, a name might be prudent. ------------------- Proposal ------------ 2010-02-17 ------------------------ ##Proposed Resolution: Duplicate Duplicate. This issue will be resolved through the disposition of Issue 14721 (JIRA ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Matthias Kloppmann (IBM) [ 08/Feb/10 07:18 AM ] |
|
(Related to The following is a snippet from the correlation of the standard seller example, using names and types on correlation properties, and names correlation keys. Search for "issue" to find the spots with the proposed changes in the example. <!--===================================================================== Collaboration: Seller entity ("concrete" participant) and Buyer/Shipper role ("abstract"/prototypical participants) =====================================================================--> <partnerEntity id="theSeller" name="The Seller"/> <partnerRole id="aBuyer" name="A Buyer"/> <partnerRole id="aShipper" name="A Shipper"/> <!--Issue Issue Proposal: Add attributes 'name' and 'type' as attributes to the schema. Name is optional with no default, type is optional and defaults to xsd:string.--> <correlationProperty id="propQuoteID" name="Property Quote ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgRFQ"> <messagePath>/request/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgQuote"> <messagePath>/response/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgFault"> <messagePath>/fault/quoteID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/priceQuotationRef</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <correlationProperty id="propCustomerID" name="Property Customer ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/customer/id</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderConfirmation"> <messagePath>/customerID</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <correlationProperty id="propOrderID" name="Property Order ID" type="xsd:string"> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderData"> <messagePath>/order/orderID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgOrderConfirmation"> <messagePath>/order/orderID</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgShippingData"> <messagePath>tbd</messagePath> </correlationPropertyRetrievalExpression> <correlationPropertyRetrievalExpression messageRef="tns:msgShippingConfirmation"> <messagePath>tbd</messagePath> </correlationPropertyRetrievalExpression> </correlationProperty> <collaboration id="sellerCollab"> <participant id="seller" name="Seller" partnerEntityRef="tns:theSeller" processRef="tns:sellerProcess"> <interfaceRef>tns:sellerServiceInterface</interfaceRef> </participant> <participant id="buyer" name="Buyer" partnerRoleRef="tns:aBuyer"/> <participant id="shipper" name="Shipper" partnerRoleRef="tns:aShipper"> <interfaceRef>tns:shipperServiceInterface</interfaceRef> </participant> <messageFlow id="mf1" messageRef="tns:msgRFQ" sourceRef="tns:aBuyer" targetRef="tns:receiveQuoteRequest"/> <messageFlow id="mf2" messageRef="tns:msgQuote" sourceRef="tns:sendQuote" targetRef="tns:aBuyer"/> <messageFlow id="mf3" messageRef="tns:msgFault" sourceRef="tns:sendFault" targetRef="tns:aBuyer"/> <messageFlow id="mf4" messageRef="tns:msgOrderData" sourceRef="tns:aBuyer" targetRef="tns:receiveOrderRequest"/> <messageFlow id="mf5" messageRef="tns:msgOrderConfirmation" sourceRef="tns:sendOrderResponse" targetRef="tns:aBuyer"/> <messageFlow id="mf6" messageRef="tns:msgShippingData" sourceRef="tns:sendShippingRequest" targetRef="tns:aShipper"/> <messageFlow id="mf7" messageRef="tns:msgShippingConfirmation" sourceRef="tns:aShipper" targetRef="tns:receiveShippingConfirmation"/> <!--===================================================================== Conversations =====================================================================--> <conversation id="conversationQuoteRequest"> <messageFlowRef>tns:mf1</messageFlowRef> <messageFlowRef>tns:mf2</messageFlowRef> <messageFlowRef>tns:mf3</messageFlowRef> <messageFlowRef>tns:mf4</messageFlowRef> <!--Issue Proposal: Add attribute 'name' as attribute to the schema. Name is optional with no default.--> <correlationKey id="correlQuote" name="Quote CorrelationKey"> <correlationPropertyRef>tns:propQuoteID</correlationPropertyRef> </correlationKey> </conversation> <conversation id="conversationOrderHandling"> <messageFlowRef>tns:mf4</messageFlowRef> <messageFlowRef>tns:mf5</messageFlowRef> <correlationKey id="correlOrder" name="Order Correlation Key"> <correlationPropertyRef>tns:propCustomerID</correlationPropertyRef> <correlationPropertyRef>tns:propOrderID</correlationPropertyRef> </correlationKey> </conversation> <conversation id="conversationShipmentRequest"> <messageFlowRef>tns:mf6</messageFlowRef> <messageFlowRef>tns:mf7</messageFlowRef> <correlationKey id="correlShipment" name="Shipment Correlation Key"> <correlationPropertyRef>tns:propOrderID</correlationPropertyRef> </correlationKey> </conversation> </collaboration> Derived from the example, here are the required changes in the XSD: <xsd:element name="correlationKey" type="tCorrelationKey"/> <xsd:complexType name="tCorrelationKey"> <xsd:complexContent> <xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element name="correlationPropertyRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"><!-- New for issue </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="correlationProperty" type="tCorrelationProperty" substitutionGroup="rootElement"/> <xsd:complexType name="tCorrelationProperty"> <xsd:complexContent> <xsd:extension base="tRootElement"> <xsd:sequence> <xsd:element ref="correlationPropertyRetrievalExpression" minOccurs="1" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"><!-- New for issues <xsd:attribute name="type" type="xsd:QName" default="xsd:string" use="optional"><!-- New for issue </xsd:extension> </xsd:complexContent> </xsd:complexType> Textual changes will be specified in detail after the outline of this proposal has been discussed and agreed upon. |
| Comment by Matthias Kloppmann (IBM) [ 09/Feb/10 08:48 AM ] |
|
Here are the remaining required changes, combined for both UML Schema -- Add attributes as per XSD above/spec table changes below Specification text: -- Figure 8.18 Correlation Class diagram Show the following added attributes in their compartments: CorrelationKey::name CorrelationProperty::name CorrelationProperty::type -- Table 8.32 CorrelationKey model associations Add the following row: name[0..1] | String | Specifies the name of the correlation key -- Table 8.33 CorrelationProperty model associations Add the following rows: name[0..1] | String | Specifies the name of the correlation property type[0..1]='String' | Element | Specifies the type of the correlation property |
| Comment by Stephen White [ 17/Feb/10 05:20 PM ] |
|
------------------- Proposal ------------ 2010-02-17 ------------------------
Duplicate. This issue will be resolved through the disposition of Issue 14721 (JIRA ---------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 17/Feb/10 05:21 PM ] |
| New Proposed Resolution |
[BPMNFTF-370] [OMG 14673] Figure 11-4 description
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-560 ##Original Info: (Severity: Significant - Nature: Revision) The first sentence of the paragraph under Figure 11-4 (Conversational view choreographies) refers to Figure 11-3, but is about Figure 11-4, as far as I can tell. How is the parent-child relation referred to at the beginning of the paragraph reflected in the notation or metamodel? It says the Planned Order Variations as being keyed on Order Id, but the figure shows it keyed on Variation ID also (compare to description of Retailer Order and Delivery Variations Ack). The paragraph refers to Conversations instead of Communication. The second paragraph under Figure 11-4 refers to Detailed Shipment Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The paragraph refers to Conversations instead of Communication. The third paragraph under Figure 11-4 refers to Delivery Planning and Special Cover, which aren't in Figure 11-3 or 4. It mentions messages spawning conversations, which isn't described anywhere else. The paragraph refers to Conversations instead of Communication. |
| Comments |
| Comment by Conrad Bock (NIST) [ 17/Apr/10 03:18 PM ] |
|
-----------Proposal----------------Apr 17, 2010---------------------------
##Proposed Resolution: Defer This issue is postponed for more discussion in RTF. |
[BPMNFTF-369] [OMG 14678] Mention of "isInterrupting" attribute still in the spec
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-555 ##Original Info: (Severity: Minor - Nature: Revision) Spec v0.9.14. Section 14.4.4 (Execution Semantics) mentions the "isInterrupting" attribute. This attribute was renamed to "cancelActivity". ------------------------ New Proposed Resolution ----------- 2010-02-01 ---------------------------- ##Proposed Resolution: Closed; No Change This issue was based on an earlier draft of the specification and is no longer valid. Thus, we will close. ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 20/Jan/10 03:45 PM ] |
|
Suzette,
Can you verify if this issue is still valid? I don't know which entity you are referring to. isInterrupting applies now to boundary events, and isInterrupting applies to start events. Thanks, |
| Comment by Stephen White [ 21/Jan/10 09:29 PM ] |
|
Boundary activities do have the cancelActivity attribute and not the isInterrupting attribute. They both mean the same thing.
However, there is one technicality about changing the Start Event attribute to cancelActivity: if the Event Sub-Process cancels a top-level Process, then then name would not be strictly accurate. A Process is not an Activity in the metamodel. I don't know how important that is, but it might explain why it wasn't changed earlier. |
| Comment by Mariano Benitez (Oracle) [ 21/Jan/10 09:52 PM ] |
|
I get it, but I believe both attributes are now properly described and I believe the distinction makes sense. At least for consistency the spec is correct now.
It is possible that the issue was created before the renaming was properly finished? If this is the case, can we close with no change? |
| Comment by Stephen White [ 24/Jan/10 09:31 PM ] |
| If Suzette is ok with closing it, I'll make the proposal. |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 12:51 PM ] |
|
Okay to close.
[Btw, I got no notifications from JIRA when the comments above were posted, even though I'm tagged as the Reporter.] |
[BPMNFTF-368] [OMG 14679] Contradiction in constraint for Start Events in Event Subprocess
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-554 ##Original Info: (Severity: Minor - Nature: Revision) Apparent contradiction, assuming I'm reading the constraint right. The spec states that "An Event Sub-Process MUST have a single Start Event". I interpret this to mean exactly one. And yet the spec allows a Start Event with a Multiple or Parallel Multiple event definition. These are short-hand for multiple Start Events, each with a single event definition. Hence a contradiction in functionality and intent. Recommend updating the spec constraint to state "An Event Sub-Process MUST have at least one Start Event". |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 03:30 AM ] |
|
As per March F2F Meeting:
- Agreed that this is an issue for implementers but not for the standard (specification). - Close (not a problem) with no changes to the specification. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:08 PM ] |
|
##Proposed Resolution: Closed, No Change
This is not a problem with the specification, so we close with no change |
[BPMNFTF-367] [OMG 14677] Incorrect description for the Transaction.protocol attribute
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-556 ##Original Info: (Severity: Minor - Nature: Revision) Spec v0.9.14. Table 10-21 contains an incorrect description for the Transaction.protocol attribute. -------- New Proposed Resolution ---------- 2010-01-14 -------------------------------- ##Proposed Resolution: Duplicate This issue is a duplicate of issue OMG 14750 ( ----------------------------------------------------------------------------------------------------------- |
[BPMNFTF-366] [OMG 14680] Are Conditional Start Events executable?
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-events.doc
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-553 ##Original Info: (Severity: Minor - Nature: Revision) Are ConditionalStartEvents executable? What data are they able to access? Note that the spec states that executable ConditionalStartEvents must have a FormalExpression. So the spec implies they are executable. But it doesn't provide guidance on what data context would be provided for that FormalExpression. ##Proposed Resolution: Fixed Section 10.4.2 Start Event Table 10.3 - Top-Level Process Start Event Types Change row: Conditional Original (Description column) This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The Condition Expression for the Event must become false and then true before the Event can be triggered again. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right). Proposal (Description column) This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The Condition Expression for the Event must become false and then true before the Event can be triggered again. The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the process (as the Process instance has not yet been created). Instead, it may refer to static process attributes and states of entities in the environment. The specification of mechanisms to access such states is out of scope of the standard. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right). |
| Comments |
| Comment by Ivana Trickovic [ 22/Mar/10 06:06 PM ] |
| proposalScheduledForBallot11 |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:47 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:47 AM ] |
|
Proposed resolution:
Section 10.4.2 Start Event Table 10.3 - Top-Level Process Start Event Types Change row: Conditional Original (Description column) This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The Condition Expression for the Event must become false and then true before the Event can be triggered again. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right). Proposal (Description column) This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The Condition Expression for the Event must become false and then true before the Event can be triggered again. The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the process (as the Process instance has not yet been created). Instead, it may refer to static process attributes and states of entities in the environment. The specification of mechanisms to access such states is out of scope of the standard. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right). |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:47 AM ] |
| New Proposed Resolution |
[BPMNFTF-365] [OMG 14672] Meaning of "+" symbol on Communication undefined
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-561 ##Original Info: (Severity: Significant - Nature: Revision) Sections 11.4 and 11.5 don't defined the meaning of + symbol on Communication. I thought it meant the expansion included at least one communication. If this is the definition, then Figure 11-3 has a nested communication symbol for Delivery Negotiations, but Figure 11-4 expands it without a communication. -----------Proposal----------------Apr 5, 2010--------------------------- ##Proposed Resolution: Fixed The definition given by the filer appears under Figure 11.4, but it is incorrect. The plus sign only indicates the presence of a SubConversation, or CallConversation to a Collaboraton, as described in those sections. In the paragraph under Figure 11.4 (Conversational view choreographies), next to last sentence, starting with "to alert", replace the rest of the sentence with ", indicating a Sub-Conversation or a CallConversation calling a Collaboration." |
| Comments |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 01:39 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 05/Apr/10 03:25 PM ] |
|
-----------Proposal----------------Apr 5, 2010---------------------------
##Proposed Resolution: Fixed The definition given by the filer appears under Figure 11.4, but it is incorrect. The plus sign only indicates the presence of a SubConversation, or CallConversation to a Collaboraton, as described in those sections. In the paragraph under Figure 11.4 (Conversational view choreographies), next to last sentence, starting with "to alert", replace the rest of the sentence with ", indicating a Sub-Conversation or a CallConversation calling a Collaboration." |
[BPMNFTF-364] [OMG 14671] isClosed on Conversation
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-562 ##Original Info: (Severity: Significant - Nature: Revision) isClosed is on Collabration and Choreography, but not Conversation. It should be promoted to Interaction. ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:15 PM ] |
| New Proposed Resolution. |
[BPMNFTF-363] [OMG 14744] Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-412 ##Original Info: (Severity: Significant - Nature: Revision) A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer). |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:14 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:43 PM ] |
| Update the issue resolution to say that this is not an implementation issue so the proposal is to defer it, instead of just saying that the FTF was not able to allocate time. |
| Comment by Ivana Trickovic [ 06/Apr/10 02:57 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-362] [OMG 14745] Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 13 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Hagen Volzer |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-411 ##Original Info: (Severity: Critical - Nature: Enhancement) The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state. If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available." |
| Comments |
| Comment by Dave Ings [ 10/Mar/09 10:35 AM ] |
|
SAP believes that modeling of Data Object states is out of scope of BPMN 2.0. This is required if we want to introduce the state of Data Objects as a performance constraint.
Steve still thinks this is an interesting issue but he agrees to defer it as it will not be resolvable in the available time. |
| Comment by Conrad Bock (NIST) [ 10/Mar/09 10:40 AM ] |
| The spec already supports Data Object state, see Figure 10-46 (DataObject class diagram) in 0.9.7. |
| Comment by Conrad Bock (NIST) [ 10/Mar/09 10:43 AM ] |
|
P.S. Since the specfalready supports Data Object state, it would be good to include it in the execution semantics.
The execution semantics description is very incomplete anyway and is critical to complete, see http://www.osoa.org/jira/browse/BPMN-415. I added a link. |
| Comment by Hagen Volzer [ 16/Mar/09 09:54 AM ] |
| My state of knowledge is also that data object state is out of scope. It can be specified but it does not affect semantics. Data object state was never considered a "performance constraint" in in sense of Sect 13 so far. |
| Comment by Hagen Volzer [ 18/Mar/09 11:49 AM ] |
| Steve, Conrad and me suggest to defer this issue. |
| Comment by Ivana Trickovic [ 09/Mar/10 08:42 AM ] |
|
As per March F2F Meeting:
- This is a request for a new feature and so it is out of scope of the FTF. - Proposal is to close (out of scope) this issue wtih no changes to the specification. |
| Comment by Stephen White [ 09/Mar/10 10:45 AM ] |
|
A new feature is not a reason that it is out of scope. According to current OMG P&Ps, new features should are more appropriate for FTFs than they are for RTFs. The real question is whether or not the new feature is large enough that it should be handled by an RFP, rather than the FTF.
The current issue is not large enough to warrant waiting for an RFP. Thus, this issue, being rather a small change, is really in scope for the FTF. |
| Comment by Mariano Benitez (Oracle) [ 22/Mar/10 11:13 AM ] |
|
By decision of the FTF Meeting 3/22
- remove the issue from Ballot 9 and wait for a resolution in Ballot 10. |
| Comment by Stephen White [ 22/Mar/10 02:58 PM ] |
| Not sure why this was critical. Reduced to major. |
| Comment by Stephen White [ 10/Apr/10 02:56 PM ] |
| Note that there are two Proposals for this issue. |
| Comment by Mariano Benitez (Oracle) [ 07/May/10 08:33 AM ] |
|
##Proposed Resolution: Closed, No Change
- This is a request for a new feature and so it is out of scope of the FTF. This new feature implies defining how the data object state is related to the data object attributes, it is not a minor issue. - Proposal is to close (out of scope) this issue wtih no changes to the specification. This can be covered by a subsequent RFP. |
| Comment by Mariano Benitez (Oracle) [ 07/May/10 08:33 AM ] |
|
##Proposed Resolution: Defer
- This is potentially a minor feature that would be suitable for an RTF. There are alternative methods for resolving this issue and the FTF did not come up with an agreement. Some resolutions would be out of scope for an RTF, but others would not. Thus, it should be deferred for further discussion by an RTF to determine it can be resolved or closed. |
[BPMNFTF-361] [OMG 14746] Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Reiner Hille-Doering |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-405 ##Original Info: (Severity: Minor - Nature: Revision) In the visual metamodel, a Choreography is visualized in a ChoreographyDiagram, a Collaboration is visualized in a CollaborationDiagram, and yet a Process is not visualized with a ProcessDiagram as I would expect but rather an OrchestrationDiagram. For consistency and clarity in terminology, the OrchestrationDiagram should be called ProcessDiagram. Was there a reason it couldn't be? ##Proposed Resolution: Closed, no change The BPMN DI does not contain diagram type as this is not needed for Diagram interchange. |
| Comments |
| Comment by Oliver Kieselbach (SAP) [ 15/Jan/09 06:30 AM ] |
| I don't think there was a special reason behind the decision to use "OrchestrationDiagram". So, it would be fine with me to rename it to "ProcessDiagram" |
| Comment by Reiner Hille-Doering [ 01/Mar/10 09:33 AM ] |
|
After the new baseline there are no such DI classes anymore. So the issue is obolete.
I suggest to close the issue. |
| Comment by Denis Gagne [ 11/Mar/10 02:15 AM ] |
|
##Proposed Resolution: Close no change
The BPMN DI does not contain diagram type as thisis not needed for Diagram interchange. |
| Comment by Mariano Benitez (Oracle) [ 11/Mar/10 07:46 AM ] |
|
New Proposed Resolution
|
[BPMNFTF-360] [OMG 14747] Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Reiner Hille-Doering |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-404 ##Original Info: (Severity: Significant - Nature: Revision) Many classes in the visual model start with BPMN. For example, BPMNDiagram, BPMNShape, etc. Given that this metamodel is part of the BPMN spec, including BPMN in class names seem extraneous. Certainly we don't do so in the semantic metamodel, so there is an inconsistency in style. Also, this style of naming generally isn't considered a recommended practice. What if BPMN is renamed in the next version? Is there a real need for this pattern? ##Proposed Resolution: Close, no change We need the prefix for Domain Specific refinement of the generic DD specification to differentiate it from the referenced element. This pattern was also done with UML. |
| Comments |
| Comment by Oliver Kieselbach (SAP) [ 15/Jan/09 06:29 AM ] |
|
I personally don't have a strong opinion about the general naming. Two motivations were driving us here: 1) we wanted to have names which clearly differentiate between a visual MM element from the corresponding semantic element to avoid confusion when talking/discussing/describing elements. 2) when Maged has shown us the Diagram Definition concept and the examples for the UML intrumentation of this DD MM, he also used names like "UMLClassDiagram", "UMLConnector" etc.
|
| Comment by Reiner Hille-Doering [ 01/Mar/10 09:31 AM ] |
|
After the the new base-lined proposal, we still have "BPMN" in the name - still Oliver's comment is valid that BPMN in the name was done to stress the fact that the classes are refinements of general DI classes for BPMN - similary to the refinements for UML.
I propose to keep the naming. |
| Comment by Denis Gagne [ 10/Mar/10 09:20 AM ] |
|
BPMN DI F2F Marc 10
We need the prefix for Domain Specific refinement of the generic DD specification to differentiate it from the referenced element ##Proposed Resolution: Close no change |
| Comment by Reiner Hille-Doering [ 19/Mar/10 04:58 AM ] |
| proposalScheduledForBallot10 |
[BPMNFTF-359] [OMG 14748] Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-activities_updatedFor359.doc
10_process-activities_updatedFor359_v2.doc
10_process-data_updatedFor359.doc
10_process-data_updatedFor359_v2.doc
10_process-events_updatedFor359.doc
10_process-events_updatedFor359_v2.doc
10_process-events_updatedFor359_v3.doc
14_execsem_updatedFor359.doc
14_execsem_updatedFor359_v2.doc
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-400 ##Original Info: (Severity: Critical - Nature: Enhancement) Is Message Flow another type of Data Association? This would mean that Messages can be mapped to the Data Inputs of Activities. Is there another way to use Message as an Activity Input? ##Proposed Resolution: Fixed Formatted versions are available here: http://www.osoa.org/jira/secure/attachment/10731/10_process-activities_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10732/10_process-data_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10735/10_process-events_updatedFor359_v3.doc http://www.osoa.org/jira/secure/attachment/10734/14_execsem_updatedFor359_v2.doc (a) Replace the first paragraph after Figure 10.11 with the following: "The Service Task inherits the attributes and model associations of Activity (see Table 103). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly one InputSet and at most one OutputSet. It has a single data input with an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef attribute of the associated operation. If the operation defines output Messages, the Service Task has a single data output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated operation." (b) Add a new paragraph immediately after Figure 10.14 with the following: "The Send Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one input set and one data input. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the data input on the Send Task into the Message to be sent. If the data input is not present, the Message will not be populated with data from the process." (c) Add a new paragraph immediately after Figure 10.15 with the following: "The Receive Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Receive Task references a Message: The Receive Task must have at most one output set and at most one data output on the Receive Task. If the data output is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Receive Task is executed, the data automatically moves from the Message to the data output on the Receive Task. If the data output is not present, the payload within the Message will not flow out of the task and into the process." (d) Section 10.3.1, last paragraph on page 182 (212 pdf): delete ", Messages" from the last sentence. (e) Table 10.52, attributes "dataInputs" and "dataOutputs": add "This is an ordered set" to their descriptions. (f) First paragraph after Table 10.54, change "outputs to the specific Activity implementations" to "outputs to specific Activity and Event implementations" (g) Section 10.3.1, Sub-Section Service Task Mapping: replace the two (2) paragraphs of the section with the following: "If the Service Task is associated with an Operation there must be a single data input on the Service Task and it must have an ItemDefinition equivalent to the one defined by the Message referred to by the inMessageRef attribute of the operation. If the operation defines output Messages, there must be a single data output and it must have an ItemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the operation." (h) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Send Task Mapping" and contents of the following: "If the Send Task is associated with a Message, there must be at most one input set and at most one data input on the Send Task. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data input is not present, the Message will not be populated with data at execution time." (i) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Receive Task Mapping" and contents of the following: "If the Receive Task is associated with a Message, there must be at most one output set and at most one data output on the Receive Task. If the data output is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data output is not present, the payload within the Message will not flow out of the Event and into the process." (j) Add a new Sub-Section after Sub-Section Script Task Mapping, with a title of "Events" and contents of the following: If any of the EventDefinitions for the Event is associated with an element that has an Item Definition (such as a Message, Escalation, Error, Signal), the following constraints apply: [bullet] If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which Event Definition. [bullet] For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message, Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the event and into the process. (k) Replace Figure 10.66: ThrowEvent.dataInputs and CatchEvent.dataOutputs to have multiplicity of 0..n (l) Section 10.4.1, Sub-Section Data Modeling and Events: Replace the 2nd sentence of the 1st paragraph with the following: "For such Events, the following constraints apply: [bullet]If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which Event Definition. [bullet]For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message, Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the event and into the process. The execution behavior is then as follows: [bullet]For Throw Events: When the event is activated, the data in the data input is automatically assigned to the Message, Signal, Escalation or Error referenced by the corresponding EventDefinition. [bullet]For Catch Events: When the trigger of the event occurs (for example, the Message is received), the data is automatically assigned to the data output that corresponds to the EventDefinition that described that trigger." (m) Section 10.4.1: Delete Sub-Section "Catch Event Data Association" and delete Sub-Section "Throw Event Data Association" (n) Table 10.75, attributes "eventDefinitionRefs", "eventDefinitions", and "dataOutputs": add "This is an ordered set" to their descriptions. (o) Table 10.76, attributes "eventDefinitionRefs", "eventDefinitions", and "dataInputs": add "This is an ordered set" to their descriptions. (p) Section 14.2.3: Replace the description of the bullet for Service Task with the following: "Upon activation, the data in the inMessage of the Operation is assigned from the data in the data input of the Service Task, and the Operation is invoked. On completion of the service, the data in the data output of the Service Task is assigned from the data in the outMessage of the Operation, and the Service Task completes. If the invoked service returns a fault, that fault is treated as interrupting error, and the Activity fails." (q) Section 14.2.3: Replace the description of the bullet for Send Task with the following: "Upon activation, the data in the associated Message is assigned from the data in the data input of the Send Task. The Message is sent and the Send Task completes." (r) Section 14.2.3: Replace the description of the bullet for Receive Task with the following: "Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the data output of the Receive Task is assigned from the data in the Message, and Receive Task completes." (s) Section 14.2.3, Bullet for User Task: Replace "instantiation" with "activation" (t) Section 14.2.3, Bullet for Manual Task: Replace "instantiation" with "activation" (u) Section 14.2.3, Bullet for Business Rule Task: Replace "instantiation" with "activation" (v) Section 14.2.3, Bullet for Script Task: Replace "instantiation" with "activation" (w) Section 14.2.3, Bullet for Abstract Task: Replace "instantiation" with "activation" |
| Comments |
| Comment by Conrad Bock (NIST) [ 05/Feb/09 08:54 AM ] |
| This would be a subtopic of BPMN-229. |
| Comment by Dave Ings [ 10/Mar/09 10:32 AM ] |
| Steve notes that this issue may arise during our samples work and if so we can resolve it in that context. Otherwise he agrees it should be deferred. |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 12:07 PM ] |
| This is a subtopic of http://www.osoa.org/jira/browse/BPMNFTF-470. |
| Comment by Stephen White [ 11/Feb/10 01:21 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
Connection between Data Objects and MF. How would set the data from a Data Object into a Message? or vice versa? Is it only in the workings of the Activity. Is that sufficient? How to get data in and out of Events? a related issue? Assign to Ivana Link to Issue 442 |
| Comment by Ivana Trickovic [ 09/Mar/10 08:49 AM ] |
|
As per March F2F Meeting:
- Yes, the common understanding is that it is only in the workings of the Activity, and looks to be sufficient. If other Activity is supposed to access any data then a mapping to a Data Object must be specified. - Therefore there is no need to change the specification. - Proposal is to close the issue with no changes to the specification. |
| Comment by Stephen White [ 09/Mar/10 11:08 AM ] |
| So there will be no way to transfer data between a Data Object and a Message except through the hidden inner workings of an Activity (or Event)? |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 11:16 AM ] |
|
I really don't understand what is meant by the first bullet in the F2F minutes above.
The way I see this working is: There would be a Data Association from the Message Event to the Data Object. That DataAssociation is responsible for extracting the data from the Message and putting it into the DataObject. And another DataAssociation from the DataObject to an Activity input. None of this is hidden or what I would call the inner workings of the Activity. So, I agree with the action of close with no change. But I'm not sure if I'm agreeing for the same reason the F2F came to that conclusion. |
| Comment by Stephen White [ 09/Mar/10 12:12 PM ] |
| But a Message is not an ItemAwareElement, So it cannot be used as a source or target for a Data Association. |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 12:35 PM ] |
|
True. The source of the Data Association would be a Data Output on the Message Event.
I couldn't find anywhere in the spec that describes how that Data Output is populated. Intuitively, I'd expect it to be populated from the Message payload. And Beta Spec pg 241 sort of describes that. But it's not clearly spelled out, or at least not that I can find. So there is some 'magic' happening that probably should be addressed. I guess that's what you meant by "hidden inner workings". Btw ... this is not just for Message data. Escalations, errors, signals should all be covered in the same way. |
| Comment by Stephen White [ 09/Mar/10 01:31 PM ] |
| Then a simple fix to all that would be to make an itemAwareElement out of any element that references an itemDefinition. I'm not sure why they are not already. Isn't that what "item Aware" means? |
| Comment by Conrad Bock (NIST) [ 09/Mar/10 02:15 PM ] |
|
Steve,
> Then a simple fix to all that would be to make an itemAwareElement > out of any element that references an itemDefinition. I'm not sure > why they are not already. Isn't that what "item Aware" means? I agree. Conrad |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 03:03 PM ] |
|
> Isn't that what "item Aware" means?
Actually, no it isn't. Or at least not currently. ItemAwareElements hold data and are specific to a particular context. Consider the fact that ItemAwareElements have a DataState. State tends to be very contextual ... at a particular point in the process, the data instances have state 'X'. This is why the ItemAwareElements are things like DataInputs or DataObjects, which are all 'local' elements within a particular context. I'm not saying we shouldn't adjust the definition of Item Aware Element, just simply pointing out the intent behind the current definition. We'd have to seriously consider what we do with DataState. Do we want DataState on global elements such as Message, Error, Escalation. [I see that DataStore is an ItemAwareElement. That's probably a mistake.] In any case, I think we need a little more than this. A particular Message may occur in many places within the process. What we really want as the Data Association source is *the* message instance that will be received by a particular message event. Again, there is that notion of context, which the Message on its own doesn't provide. We could infer the context based ownership of the data association. That is, because the data association is owned by a message event, the message it is refering to is actually the message within the context of the message event. So some additional text and explanation would be needed in the spec. An alternate (and also simple) fix would be to state that, when the message arrives, its payload, if there is one, automatically transfers to the Data Output with the same ItemDefinition on the message event. it there is no Data Output with the same ItemDefinition, then the payload does not flow out of the event. And a reverse statement for the throw events. This then just involves a change to the execution semantics, with no MM or other spec impacts. It would also work for errors, signals, etc. |
| Comment by Stephen White [ 09/Mar/10 03:30 PM ] |
|
>An alternate (and also simple) fix would be to state that, when the message arrives, its payload, if there is one, automatically transfers to the Data Output with the same ItemDefinition on the message event. it there is no Data Output with the same ItemDefinition, then the payload does not flow out of the event. And a reverse statement for the throw events. This then just involves a change to the execution semantics, with no MM or other spec impacts. It would also work for errors, signals, etc.
This might work. It would have to be reversed for sending Messages. It would mean that the Inputs/Outputs would have to match the Messages--there would be no transformation between them |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 03:35 PM ] |
| Right. That would be the implication. If any transformation is needed, it could only happen on the data association from the event Data Output to the Data Object. |
| Comment by Conrad Bock (NIST) [ 09/Mar/10 04:03 PM ] |
|
Suzette,
> > [Steve] Then a simple fix to all that would be to make an > > itemAwareElement out of any element that references an > > itemDefinition. I'm not sure why they are not already. Isn't that > > what "item Aware" means? > [Suzette] Actually, no it isn't. Or at least not currently. > ItemAwareElements hold data and are specific to a particular context. > [snip] We'd have to seriously consider what we do with DataState. Do > we want DataState on global elements such as Message, Error, > Escalation. Oops, you're right, Message isn't contextual, so isn't an ItemAwareElement. But to clarify, state applies to the item, rather than the context. It means runtime item is in the specified state, at least that was the intention I recall when it was introduced. So Message (which is a type) could be required to be in a certain state, for example have particular values for some of its attributes. It looks like state is one of those "stubs" for others systems to define, so it could apply to anything. > [I see that DataStore is an ItemAwareElement. That's probably a > mistake.] If DataStore is global, then I'd agree it's a mistake to be item aware, which is contextual as you say. > An alternate (and also simple) fix would be to state that, when the > message arrives, its payload, if there is one, automatically > transfers to the Data Output with the same ItemDefinition on the > message event. This would be a good shortcut. Presumably there's only at most Data Output on a message receipt, which should be required to be of the same ItemDef as the message received. We should do the same for inputs to message sends. Conrad |
| Comment by Stephen White [ 09/Mar/10 05:05 PM ] |
|
Page 211 (241 pdf) has something to say about this:
"Catch Event Data Association The Data Association for a Catch Event is performed after the trigger of the Catch Event occurs (Message, Signal, Error, Escalation, Multiple data is available in the Catch Event). The Data Association assigns the data of the Event to a Data Element that is in the scope of the Catch Event. After that, Sequence Flow continues as usual. For example, consider a Receive Message Intermediate Event; as soon as the Message is received by the Event, the Data Association is performed and the Message data is assigned for example to a Data Object of the Process." This is a bit fuzzy since it mentions a Data Association from the Event Data (e.g., a Message), which can't happen directly. This should be clarified that the Message data is automatically pushed to an Event Output (without a Data Association). Also, if there is a Message, then there MUST be an output and that the Output MUST have the same structure (itemDefinition?) as the Message. Then the Modeler can add a Data Association to pass data from the Event Output to a Data Object(s). This would be more complicated for a Receive Task, since an Activity can have more than one Output. |
| Comment by Ivana Trickovic [ 10/Mar/10 11:27 PM ] |
|
As per March F2F Meeting:
Agreed to make the following changes: 1. The following integrity constraint to be added: Data input of events must match what is thrown and similar for catch events. The specification should clarify this for all events that hold item definitions. Similar for activities (send task, receive task, and service task). 2. Execution semantics: in section 14.3 clarify that the inputs of tasks/events will be coped in messages (what will be thrown). Similar for tasks (including faults). |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:03 PM ] |
|
Ignore the above.
proposalScheduledForBallot11 |
| Comment by Mariano Benitez (Oracle) [ 23/Mar/10 04:12 PM ] |
|
I assume this sentence in section 10.3.1 will be modified then:
"The elements in the specification defined as item-aware elements are: Data Objects, Data Stores, Properties, DataInputs and DataOutputs, --->Messages<---". |
| Comment by Suzette Samoojh (IBM) [ 23/Mar/10 04:15 PM ] |
| I hadn't noticed that sentence. But yes, you're right. It would have to be modified. |
| Comment by Stephen White [ 24/Mar/10 05:51 PM ] |
| Reduced from critical to major |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 03:11 PM ] |
|
See proposed changes in the attached files. I will document the changes directly in this JIRA issue in the form that is appropriate for the ballot and report after the changes have gone through a review with the subteam.
|
| Comment by Ivana Trickovic [ 19/Apr/10 03:37 PM ] |
| As per 4/19 FTF meeting: Move on ballot #12 |
| Comment by Suzette Samoojh (IBM) [ 21/Apr/10 05:56 PM ] |
|
Updated proposal in Word docs:
http://www.osoa.org/jira/secure/attachment/10731/10_process-activities_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10732/10_process-data_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10735/10_process-events_updatedFor359_v3.doc http://www.osoa.org/jira/secure/attachment/10734/14_execsem_updatedFor359_v2.doc Summary of key changes: - Removed the need for multiple input sets/output sets on events. Instead multiple data inputs/outputs will be used. - Added a comment that the MM diagram for events needs to be updated. Is currently out-of-synch with the spec tables and XSD. - Added 'is ordered' statements to the descriptions for CatchEvent.eventDefinition, CatchEvent.eventDefinitionRef, CatchEvent.dataOutputs, ThrowEvent.eventDefinition, ThrowEvent.eventDefinitionRef, ThrowEvent.dataInputs. Since this proposal relies on the order of these elements. |
| Comment by Suzette Samoojh (IBM) [ 26/Apr/10 04:39 PM ] |
|
-- Updated proposal------------------------------------------------------------------
Formatted versions are available here: http://www.osoa.org/jira/secure/attachment/10731/10_process-activities_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10732/10_process-data_updatedFor359_v2.doc http://www.osoa.org/jira/secure/attachment/10735/10_process-events_updatedFor359_v3.doc http://www.osoa.org/jira/secure/attachment/10734/14_execsem_updatedFor359_v2.doc (a) Replace the first paragraph after Figure 10.11 with the following: "The Service Task inherits the attributes and model associations of Activity (see Table 103). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly one InputSet and at most one OutputSet. It has a single data input with an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef attribute of the associated operation. If the operation defines output Messages, the Service Task has a single data output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated operation." (b) Add a new paragraph immediately after Figure 10.14 with the following: "The Send Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one input set and one data input. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the data input on the Send Task into the Message to be sent. If the data input is not present, the Message will not be populated with data from the process." (c) Add a new paragraph immediately after Figure 10.15 with the following: "The Receive Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Receive Task references a Message: The Receive Task must have at most one output set and at most one data output on the Receive Task. If the data output is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Receive Task is executed, the data automatically moves from the Message to the data output on the Receive Task. If the data output is not present, the payload within the Message will not flow out of the task and into the process." (d) Section 10.3.1, last paragraph on page 182 (212 pdf): delete ", Messages" from the last sentence. (e) Table 10.52, attributes "dataInputs" and "dataOutputs": add "This is an ordered set" to their descriptions. (f) First paragraph after Table 10.54, change "outputs to the specific Activity implementations" to "outputs to specific Activity and Event implementations" (g) Section 10.3.1, Sub-Section Service Task Mapping: replace the two (2) paragraphs of the section with the following: "If the Service Task is associated with an Operation there must be a single data input on the Service Task and it must have an ItemDefinition equivalent to the one defined by the Message referred to by the inMessageRef attribute of the operation. If the operation defines output Messages, there must be a single data output and it must have an ItemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the operation." (h) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Send Task Mapping" and contents of the following: "If the Send Task is associated with a Message, there must be at most one input set and at most one data input on the Send Task. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data input is not present, the Message will not be populated with data at execution time." (i) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Receive Task Mapping" and contents of the following: "If the Receive Task is associated with a Message, there must be at most one output set and at most one data output on the Receive Task. If the data output is present, it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data output is not present, the payload within the Message will not flow out of the Event and into the process." (j) Add a new Sub-Section after Sub-Section Script Task Mapping, with a title of "Events" and contents of the following: If any of the EventDefinitions for the Event is associated with an element that has an Item Definition (such as a Message, Escalation, Error, Signal), the following constraints apply: [bullet] If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which Event Definition. [bullet] For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message, Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the event and into the process. (k) Replace Figure 10.66: ThrowEvent.dataInputs and CatchEvent.dataOutputs to have multiplicity of 0..n (l) Section 10.4.1, Sub-Section Data Modeling and Events: Replace the 2nd sentence of the 1st paragraph with the following: "For such Events, the following constraints apply: [bullet]If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which Event Definition. [bullet]For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message, Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the event and into the process. The execution behavior is then as follows: [bullet]For Throw Events: When the event is activated, the data in the data input is automatically assigned to the Message, Signal, Escalation or Error referenced by the corresponding EventDefinition. [bullet]For Catch Events: When the trigger of the event occurs (for example, the Message is received), the data is automatically assigned to the data output that corresponds to the EventDefinition that described that trigger." (m) Section 10.4.1: Delete Sub-Section "Catch Event Data Association" and delete Sub-Section "Throw Event Data Association" (n) Table 10.75, attributes "eventDefinitionRefs", "eventDefinitions", and "dataOutputs": add "This is an ordered set" to their descriptions. (o) Table 10.76, attributes "eventDefinitionRefs", "eventDefinitions", and "dataInputs": add "This is an ordered set" to their descriptions. (p) Section 14.2.3: Replace the description of the bullet for Service Task with the following: "Upon activation, the data in the inMessage of the Operation is assigned from the data in the data input of the Service Task, and the Operation is invoked. On completion of the service, the data in the data output of the Service Task is assigned from the data in the outMessage of the Operation, and the Service Task completes. If the invoked service returns a fault, that fault is treated as interrupting error, and the Activity fails." (q) Section 14.2.3: Replace the description of the bullet for Send Task with the following: "Upon activation, the data in the associated Message is assigned from the data in the data input of the Send Task. The Message is sent and the Send Task completes." (r) Section 14.2.3: Replace the description of the bullet for Receive Task with the following: "Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the data output of the Receive Task is assigned from the data in the Message, and Receive Task completes." (s) Section 14.2.3, Bullet for User Task: Replace "instantiation" with "activation" (t) Section 14.2.3, Bullet for Manual Task: Replace "instantiation" with "activation" (u) Section 14.2.3, Bullet for Business Rule Task: Replace "instantiation" with "activation" (v) Section 14.2.3, Bullet for Script Task: Replace "instantiation" with "activation" (w) Section 14.2.3, Bullet for Abstract Task: Replace "instantiation" with "activation" |
| Comment by Mariano Benitez (Oracle) [ 27/Apr/10 06:13 AM ] |
| updated proposal based on Suzette's update |
| Comment by Falko Menge [ 09/Jun/10 10:50 AM ] |
|
spec-May24-review
Item (j) defines a headline to be 'Events'. However, the headline of the according paragraph in the convenience documents is 'Send Task Mapping'. Proposal: Replace 'Send Task Mapping' with 'Events' in the sub-section added by item (j). |
[BPMNFTF-358] [OMG 14749] [Section 10.6] Editorial: We need more explicit descriptions of Compensation behaviour regarding scopes.
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-398 ##Original Info: (Severity: Significant - Nature: Revision) I believe we need to be more clear/explicit when describing several aspects of compensations. I base this on 0.9.2 - We should made clear on each case what context is used in compensation. This is a refinement of the snapshot concept, but it needs clarification in this cases: -- Boundary event handlers: it only mention "black-box" compensation, when it should clearly state that the current state is used. -- inline event sub-processes: they mention the snapshot when the process is completed, but there is no mention to the case when the compensation is triggered while the subprocess is still running. Also it should be described that the parent scope used in the compensation is the current one, even when the compensated subprocess uses the snapshot context. ##Proposed Resolution: Close, No Change The assumption made when reporting this issues was that a compensation can compensate a running activity, which is wrong, only completed activities can be compensated. So this issue is invalid. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
[BPMNFTF-357] [OMG 14750] [Section 10.2.3] Editorial: protocol attribute on the transaction subprocess class seems to have a wrong description - TransactionMethod values not explained
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-396 ##Original Info: (Severity: Significant - Nature: Revision) This is the description Transaction->protocol attribute in 0.9.2 (page 156): The elements that make up the internal Sub-Process flow. This association is only applicable when the XSD Interchange is used. In the case of the XMI interchange, this association is inherited from the FlowElementsContainer class. Also, the TransactionMethod values are not fully explained. I can infer compensate, but I don't understand Store or Image. ##Proposed Resolution: Fixed Clarification: Attribute "protocol" is not needed as Transaction Sub-Process has attribute "flowElements" inherited from class Sub-Process. Proposal for The proposal is to make the following changes in Beta 1: (1) Section 10.2.5 Table 10.21: Remove attribute "protocol" (the complete row). (2) Update the XSD, so that Transaction inherits from SubProcess as stated in the specification text and MM: Add <xsd:complexType name="tTransaction"> <xsd:complexContent> <xsd:extension base="tSubProcess"/> ... </xsd:complexContent> </xsd:complexType> instead of <xsd:complexType name="tTransaction"> <xsd:complexContent> <xsd:extension base="tActivity"/> ... </xsd:complexContent> </xsd:complexType> |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 09/Mar/10 04:59 PM ] |
|
Matthias, we discussed a similar issue in the F2F, I am assigning this issue to you so you can merge them.
(this one presents one more problem, but it can be easily fixed) |
| Comment by Stephen White [ 24/Mar/10 07:48 PM ] |
|
New Proposed Resolution
Lowered Priority from Major to Minor Based on Conference Call on 2010-03-24 |
| Comment by Ivana Trickovic [ 04/Apr/10 11:44 PM ] |
|
Move on ballot #11 as the related issue |
| Comment by Ivana Trickovic [ 19/Apr/10 07:24 AM ] |
|
The second part of the issue (the TransactionMethod attribute) will be resolved (see The first part (the Protocol attribute) should still be resolved. I propose move this issue in ballot #12 and provide a proposal for the first part of the issue. |
| Comment by Ivana Trickovic [ 19/Apr/10 03:37 PM ] |
| As per 4/19 FTF meeting: Moved on ballot #12 |
| Comment by Ivana Trickovic [ 20/Apr/10 04:57 PM ] |
|
##Proposed Resolution: Fixed
Clarification: Attribute "protocol" is not needed as Transaction Sub-Process has attribute "flowElements" inherited from class Sub-Process. Proposal for OMG 14335 resolves the second part of the issue. The proposal is to make the following changes in Beta 1: (1) Section 10.2.5 Table 10.21: Remove attribute "protocol" (the complete row). (2) Update the XSD, so that Transaction inherits from SubProcess as stated in the specification text and MM: Add <xsd:complexType name="tTransaction"> <xsd:complexContent> <xsd:extension base="tSubProcess"/> ... </xsd:complexContent> </xsd:complexType> instead of <xsd:complexType name="tTransaction"> <xsd:complexContent> <xsd:extension base="tActivity"/> ... </xsd:complexContent> </xsd:complexType> |
[BPMNFTF-356] [OMG 14751] Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-395 ##Original Info: (Severity: Significant - Nature: Revision) The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes. A general question: Parameter is a very generic name. Should this class be named something more specific? ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 24/Mar/10 07:49 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:45 PM ] |
| Move this on ballot #11. The Parameter class shall be fully described as all other classes in the specification. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
| Comment by Ivana Trickovic [ 26/Apr/10 06:34 AM ] |
|
Steve, could you please check the issue as I could not reproduce it?
If this issue is obsolete it should be closed. |
[BPMNFTF-355] [OMG 14752] Diagram Interchange should align with Diagram Type Definition
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Oliver Kieselbach (SAP) |
| Resolution: | Duplicate | Votes: | 0 |
| File Attachments: |
BPMN-DI-DD.ppt
diagram-definition-ibm-slides-ad-08-12-08.pdf
Elaasar 1 First Approach.jpg
Elaasar 2 Second Approach.jpg
Elaasar DI Two Approaches.pdf
|
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-384 ##Original Info: (Severity: Critical - Nature: Revision) This summarizes a conversation with Maged, we agreed an issue should be filed. He said there were two approaches to diagram interchange (which he can explain more about). The one in the IOS submission was chosen for expediency and IBM will not be submitting it to the OMG's Diagram Type Definition RFP (DTD). The differences between the approaches is too much to resolve in an FTF. The IOS submission should use the same diagram interchange as IOS members (IBM at least) are submitting for DTD. Then any remaining differences between IOS and the later DTD adoption can be resolved in FTF. -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14423 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Conrad Bock (NIST) [ 19/Dec/08 11:08 AM ] |
|
The first figure attached is Maged's showing the option taken for
expediency in the IOS submission (option "1"). The second is Maged's showing his team's submission to ADTF Diagram Type Definition. The presentation files are attached covering the two options and the IBM submission to ADTF. |
| Comment by Bruce Silver [ 19/Dec/08 05:03 PM ] |
|
I have a feeling this could take many months to resolve. Currently DI specifies 2 kinds of information: 1) graphics info about elements in the semantic model, i.e. position and size of shapes, connector bendpoints, etc.; and 2) ALL info about elements not in the semantic model, e.g. lanes, annotations, and proposed pages ( |
| Comment by Conrad Bock (NIST) [ 19/Dec/08 06:15 PM ] |
|
Assuming DI is finished in the current spec, the alignment with DTD
wouldn't be hard, as I understand it from Maged. If it's not done in the current spec, then there's alot of work to do anyway. OMG won't accept two ways of exchanging diagrams. I don't agree about diagram interchange not being important. Losing diagrammatic interchange for a graphical language means there really is no interchange, except for analysis. Lanes should be in the metamodel in any case, see http://www.osoa.org/jira/browse/BPMN-264. |
| Comment by Conrad Bock (NIST) [ 06/Jan/09 02:53 PM ] |
|
Oliver (I think) said at the January 5 meeting that Maged mentioned the
above to him and would be drawing up a sketch for a proposed solution. |
| Comment by Dave Ings [ 14/Jan/09 04:28 PM ] |
| 384 open issue assign to Oliver note that goal is architectural alignment to facilitate future migration but *not* detailed class mapping |
| Comment by Ivana Trickovic [ 02/Feb/09 04:41 AM ] |
| "BPMN-DI-DD.ppt" slide deck provides additional information. |
| Comment by Oliver Kieselbach (SAP) [ 02/Mar/09 11:00 AM ] |
| The new Architecture has been applied to spec version 0.95 section 12 |
| Comment by Ivana Trickovic [ 07/Dec/09 04:55 AM ] |
|
Duplicate of |
[BPMNFTF-354] [OMG 14753] [Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Kloppmann (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-374 ##Original Info: (Severity: Significant - Nature: Revision) Revision of Spec: 0.9.1 Section(s) of Spec: Raised by: Matthias Kloppmann Sub-Team responsible: Type: Technical Description of issue: The execution semantics for exclusive gateways correctly states that "the conditions [of the outgoing sequence flows] are evaluated in order". However, the meta-model for an exclusive gateway does not allows for the specification of that order. Proposal: Using the "appropriate means" (prototype statement?), ensure the relationship from a FlowNode to its outgoing sequence flows is an ordered collection, rather than a set. This provides ordering not only for an exclusive gateway, but for all FlowNodes, but that doesn't seem to harm. In the XSD, where the sequence flows reference their source node rather than vice versa, an additional attribute or element to render the order may be needed, or the representation of sequence flow in the XSD may need to be revised. ##Proposed Resolution: Fixed (a) Update Table 8.61 (pg 131) Append the following to the description for the 'outgoing' association: This is an ordered collection. The UML Metamodel used as base for XSD and XMI will be updated to reflect this change |
| Comments |
| Comment by Stephen White [ 09/Dec/08 10:59 AM ] |
| Since this was part of BPMN 1.1, then we might consider this a critical issue. |
| Comment by Suzette Samoojh (IBM) [ 09/Dec/08 06:14 PM ] |
|
Steve, can you direct me to where this was solved in BPMN 1.1? I couldn't find it. Or is this implicit in the Gates?
Baring a better solution from BPMN, I'd recommend we: - Address in the metamodel by applying the "ordered" property string on the outgoing association. This is supported by UML ... I just need to figure out how to enter it into RSM so it generates to the XMI. - Address in the XSD by adding the reverse reference, i.e. an "outgoing" element on FlowNode. We should also explicitly document in the spec that this is an ordered list. |
| Comment by Stephen White [ 10/Dec/08 01:12 AM ] |
|
Suzette, BPMN 1.1 did not so much solve it as define it. It says in 9.5.2:
"The conditions for the alternative Gates should be evaluated in a specific order. The first one that evaluates as TRUE will determine the Sequence Flow that will be taken. Since the behavior of this Gateway is exclusive, any other conditions that may actually be TRUE will be ignored--only one Gate can be chosen. One of the Gates may be "default" (or otherwise), and is the last Gate considered. This means that if none of the other Gates are chosen, then the default Gate will be chosen—along with its associated Sequence Flow." But it did not say how this was to be done. The attribute table only listed that there are 0..* Gates. |
| Comment by Matthias Kloppmann (IBM) [ 09/Jun/09 09:54 AM ] |
| Couldn't quickly see whether this issue is address in the latest spec, so decided to mark it for the FTF. |
| Comment by Suzette Samoojh (IBM) [ 09/Jun/09 06:02 PM ] |
| Good you marked it, because it hasn't been addressed. |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:32 AM ] |
| I could not find a way to formally indicate this in the metamodel. So will rely on textual description in the spec. |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 11:36 AM ] |
|
-----Proposal---------------- 02/16/2010 -------------------------
##Proposed Resolution: Fixed (a) Update Table 8.61 (pg 131) Append the following to the description for the 'outgoing' association: This is an ordered collection. |
| Comment by Stephen White [ 22/Feb/10 06:11 PM ] |
|
For Pete Rivett:
I noticed at http://www.osoa.org/jira/browse/BPMNFTF-354 that you stated "I could not find a way to formally indicate this in the metamodel. So will rely on textual description in the spec." That's surprising: in the UML model you should be able to mark an association end as isOrdered: this is shown on the diagram as {ordered}. |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 03:31 PM ] |
| New Proposed Resolution (from Suzette) |
| Comment by Ivana Trickovic [ 10/Mar/10 04:31 AM ] |
|
As per March F2F Meeting:
- The proposal should be updated indicate that the ordering should be included in the metamodel (not just in the specification text). - Updated proposal to be added to ballot #9. |
[BPMNFTF-353] [OMG 14665] Exclusive gateways in choreography cover splitting but not merging.
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-568 ##Original Info: (Severity: Significant - Nature: Revision) The section on exclusive gateways in choreography covers splitting but not merging gateways. ##Proposed Resolution: Duplicate The resolution of this issue is covered by BPMNFTF-340 OMG-14656 |
[BPMNFTF-352] [OMG 14670] Choreography Complex Gateway example
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Falko Menge |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Compex Gateway in Choreography (Choreography) Proposal 2010-04-20.png
Compex Gateway in Choreography (Collaboration) Proposal 2010-04-20.png
Compex Gateway in Choreography Proposal 2010-04-20.vdx
Complex Gateway in Choreography (Choreography) Proposal 2010-04-20 fixed.png
Complex Gateway in Choreography Proposal 2010-04-20 fixed.vdx
|
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-563 ##Original Info: (Severity: Significant - Nature: Revision) Section 12.6.5 (Complex Gateway) has a figure that doesn't match the text example. |
| Comments |
| Comment by Falko Menge [ 20/Apr/10 04:29 PM ] |
| The attachment 'Compex Gateway in Choreography Proposal 2010-04-20.vdx' contains updated versions of Figure 12.48 and Figure 12.49. |
| Comment by Falko Menge [ 20/Apr/10 04:48 PM ] |
|
----Proposal---------------- 04/07/2010 -------------------------
##Proposed Resolution: Fixed (a) Exchange Figure 12.48 with the diagram depicted here: http://www.osoa.org/jira/secure/attachment/10728/Compex+Gateway+in+Choreography+%28Choreography%29+Proposal+2010-04-20.png (b) Exchange Figure 12.49 with the diagram depicted here: http://www.osoa.org/jira/secure/attachment/10729/Compex+Gateway+in+Choreography+%28Collaboration%29+Proposal+2010-04-20.png (c) Section 12.7.5: Exchange the second paragraph: "Consider an e-tender which sends a request for quote to service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out each request and anticipates a response through two Choreography Activities with a sequential flow between these. The request-response branches merge at a Complex Gateway to model the requirement that when 60% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. All up a maximum of 3 tenders is run. A key issue is to ensure that the responses should not be mixed across tender iterations." with the following text: "Consider an e-tender which sends a request for quote to multiple service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out requests to each service provider and anticipates their response through three Choreography Activities. The response branches merge at a Complex Gateway to model the requirement that when 66% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. A key issue is to ensure that the responses should not be mixed across tender iterations. A Terminate End Event ensures that all activities are terminated, when a tender has been successful." |
| Comment by Falko Menge [ 20/Apr/10 04:49 PM ] |
| New Proposed Resolution |
| Comment by Falko Menge [ 30/Apr/10 05:38 PM ] |
|
As Denis pointed out, a Choreography Task can only have 2 participant bands. Hence, the Choreography Task "Request for Quote" needs to be changed into a Sub Choreography to be syntactically correct.
The attachment 'Complex Gateway in Choreography Proposal 2010-04-20 fixed.vdx' includes this small change. |
| Comment by Falko Menge [ 30/Apr/10 05:43 PM ] |
| For better comparison, the attachment 'Complex Gateway in Choreography (Choreography) Proposal 2010-04-20 fixed.png' contains a screenshot of the updated Choreography. |
| Comment by Falko Menge [ 03/May/10 12:04 PM ] |
| As per FTF call on 2010-05-03, we decided to address the previous two comments on this issue as part of BPMNFTF-312. |
[BPMNFTF-351] [OMG 14669] Parallel Gateway participants
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Alistair Barros |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-564 ##Original Info: (Severity: Significant - Nature: Revision) Section 12.6.4 (Parallel Gateway) says "They create parallel paths of the Choreography that all Participants are aware of." Not all participants, only those involved after the gateway. ##Proposed Resolution: Defer The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF |
| Comments |
| Comment by Stephen White [ 18/Mar/10 04:15 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-350] [OMG 14666] Rules for exclusive gateway in choreography too strict
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Alistair Barros |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-567 ##Original Info: (Severity: Significant - Nature: Revision) Exclusive gateways in choreography are required to use decision data accessible to all participants involved in the gatway. But if if the senders after gateway are the same, then receivers can use event gateways or event subprocess to wait for event that might never come. It isn't necessary for the receivers to have access to the decision data. ##Proposed Resolution: Defer The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:12 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-349] [OMG 14661] PartnerRole underspecified and misnamed
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-572 ##Original Info: (Severity: Significant - Nature: Revision) PartnerRole does not specify the context of the role (is it a role in an organization?). The examples given (a buyer, seller, or manufacturer) could just be Participants, rather than PartnerRoles. The term "role" also conflicts with Participants, which are effectively roles in Interactions. |
| Comments |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 09:58 AM ] |
| proposalScheduledForBallot10 |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 09:31 AM ] |
| New Proposed Resolution: Defer |
| Comment by Ivana Trickovic [ 04/Apr/10 11:35 PM ] |
| Update the proposed issue resolution to clarify that this is not an implementation issue so it is deferred to RTF. |
| Comment by Ivana Trickovic [ 06/Apr/10 02:42 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF. |
[BPMNFTF-348] [OMG 14667] Multiple senders after event-based gateway in choreography
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Alistair Barros |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-566 ##Original Info: (Severity: Significant - Nature: Revision) About event-based gateways in choreography, the spec says: [Event-based] Gateways are used in Choreography when the data used to make the decision is only visible to the internal Processes of one Participant. On the right side of the Gateway [CB: I assume this means immediately after]: either the senders MUST be the same; or the receivers MUST be the same. If the decision criteria is private to one participant, how can there multiple senders after the gateway? ##Proposed Resolution: Defer The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF |
| Comments |
| Comment by Stephen White [ 18/Mar/10 04:15 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-347] [OMG 14663] Interactions supporting interactions
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-570 ##Original Info: (Severity: Significant - Nature: Revision) When a business commits to an interaction with potential business partners, it might be that a particular partner needs only some of the interaction. This would be specified in another interaction diagram. The modeler needs to link these two interactions to say one supports the other, with the same semantics of the currently supports association, except applied to messaging rather than activities. The supports association should be generalized to cover interactions. |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:01 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:32 AM ] |
| See comment http://www.osoa.org/jira/browse/BPMNFTF-335#action_16137. |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 02:54 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Defer The beta specification currently enables abstraction in processes, but not interactions, which is inconsistent and disables common interaction use cases, for example as described in the issue. Resolving this requires a modeler declaration indicating "runtime" message exchanges between businesses following one interaction also follow another. This means message exchanges can occur in reality that are not modeled in the more abstract interaction model. The resolution would be very similar to the same capability for processes, but requires explanation and examples, which can be provided in RTF, and coordination with resolution of BPMNFTF-378 [OMG 14686]. |
[BPMNFTF-346] [OMG 14662] Private process type
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-571 ##Original Info: (Severity: Significant - Nature: Revision) Modelers should be able to declare a process private without committing to whether it is executable or non-executable. Add private as a value for the type attribute. -------------------- Proposal ----------- 2010-01-28 --------------------------------- ##Proposed Resolution: Fixed (a) In Figure 10.2, 10.3, and other metamodel figures where Process appears with its attributes, insert a new attribute beneath processType: "isExecutable : Boolean". In Table 10.1 (Process Attributes & Model Associations), processType row, change as follows: left column (b) replace "executable | non-executable" with "private". right column (c) replace the second through fourth paragraphs (from "The BPMN 1.2 processType" through "not included in a non-executable Process.") with "A private process is one that is internal to a specific organization." insert new row below processType: left column isExecutable : Boolean [0..1] right column (d) First paragraph: "An optional Boolean value specifying whether the process is executable". (e) Move the current third and fourth paragraphs from the processType row to this row after the first paragraph (starting from "An executable Process" through "included in a non-executable Process.") (f) Add paragraph at end: "For public processes, no value has the same semantics as if the value were false. The value may not be true for public processes." In the following tables and rows, in the right column, replace all occurrences of "processType" with "isExecutable" and and all occurrences of "executable" with "true". (g) Table 10.3 (Activity attributes and model associations), loopCharacteristics row. (h) Table 10.88 (ConditionalEventDefinition model associations), condition row. (i) Table 10.89 (ErrorEventDefinition attributes and model associations), errorCode row. (j) Table 10.90 (EscalationEventDefinition attributes and model associations), escalationCode and timeCycle rows. (k) Table 10.92 (MessageEventDefinition model associations), messageRef. (l) In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes), second bullet, next to last sentence, replace "executable or non-executable" with "private". In Table 10.129 (Process XML schema): (m) In tProcessType element, replace enumeration values "executable" and "non-executable" with a single value "private ". (n) Add element after processType for isExecutable boolean attribute, no default: <xsd:attribute name="isExecutable" type="xsd:boolean"/> ----------------------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 27/Jan/10 06:38 PM ] |
|
---------- Discussion during Conference Call on 2010-01-27 ----------------------
How to allow the modeler to define private without worrying about executable or non? Add a fifth process type? But this would be somewhat redundant with executable and non. Could fall back to none It was decided to add "private" to the ProcessType and then move "executable" and "non-executable" to a separate attribute. This would be more flexible and would allow users to have public - executable processes in the future (if that turns out to be the case). |
| Comment by Conrad Bock (NIST) [ 28/Jan/10 05:29 PM ] |
|
-------------------- Proposal ----------- 2010-01-28 ---------------------------------
##Proposed Resolution: Fixed In Figure 10.2, 10.3, and other metamodel figures where Process appears with its attributes, insert a new attribute beneath processType: "isExecutable : Boolean". In Table 10.1 (Process Attributes & Model Associations), processType row, change as follows: left column replace "executable | non-executable" with "private". right column replace the second through fourth paragraphs (from "The BPMN 1.2 processType" through "not included in a non-executable Process.") with "A private process is one that is internal to a specific organization." insert new row below processType: left column isExecutable : Boolean [0..1] right column First paragraph: "An optional Boolean value specifying whether the process is executable". Move the current third and fourth paragraphs from the processType row to this row after the first paragraph (starting from "An executable Process" through "included in a non-executable Process.") Add paragraph at end: "For public processes, no value has the same semantics as if the value were false. The value may not be true for public processes." In the following tables and rows, in the right column, replace all occurrences of "processType" with "isExecutable" and and all occurrences of "executable" with "true". Table 10.3 (Activity attributes and model associations), loopCharacteristics row. Table 10.88 (ConditionalEventDefinition model associations), condition row. Table 10.89 (ErrorEventDefinition attributes and model associations), errorCode row. Table 10.90 (EscalationEventDefinition attributes and model associations), escalationCode and timeCycle rows. Table 10.92 (MessageEventDefinition model associations), messageRef. In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes), second bullet, next to last sentence, replace "executable or non-executable" with "private". In Table 10.129 (Process XML schema): In tProcessType element, replace enumeration values "executable" and "non-executable" with a single value "private ". Add element after processType for isExecutable boolean attribute, no default: <xsd:attribute name="isExecutable" type="xsd:boolean"/> |
| Comment by Stephen White [ 03/Feb/10 04:27 PM ] |
|
-------------------- Discussion during Converence call on 2010-02-03 -----------------------
Change enumeration for Process Type to: Private Public Undefined A new attribute: isExecutable, which is boolean allows saying private without defined executabiliity Public must be False isExecutable is optional All are user declarations -- only intentions Not changing current capabilities Gives the keyword Private Allows user to define private without committing to executable or not leaves executability undefined public is not executable already, thus there is some ambiguity from the non-executable type, which applies both to private and public (even though the description discusses it as being for private. No full consensus yet about value of changing spec and adding another attribute. Action: keep proposal, leave as boolean |
[BPMNFTF-345] [OMG 14668] Event-based gateways in choreography should be exclusive
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-565 ##Original Info: (Severity: Significant - Nature: Revision) An event-based gateway implies a message is being waited for, but choreographies can't receive messages, they have no central controller. One of the participants will have an event-based gateway internally, but the other will have a exclusive gateway. The choreography can use an exclusive gateway with no conditions, with the semantics is that exactly one of the following messages will be sent. |
| Comments |
| Comment by Conrad Bock (NIST) [ 13/Jul/09 03:53 PM ] |
|
Email from Frank about conditions on exclusive gateways in choreographies:
Hello Conrad, In my opinion there is no need to even have data as decision criteria. There may be a button, that a user presses (request xy..). Of course you can discuss, that the fact, that a button has been pressed is in itself data in the system. But it is a different kind of. So in the case of two senders there are two users and two buttons. Whoever presses first sends first. Whoever sends second is in a different branch of the choreography. That's how I understand it. Best Regards, Frank |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 10:29 AM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
[BPMNFTF-344] [OMG 14664] Processes supporting interactions
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-569 ##Original Info: (Severity: Significant - Nature: Revision) When a private process supports an interaction, this currently can only be captured by defining a public process for the private one to support, and including the public process in a collaboration, with further links to choreographies or conversations, if those were the interaction model being supportted. Private processes should be able to support any of the interaction models directly. ------------- New Proposed Resolution ----- 2010-02-03 ------------- ##Proposed Resolution: Close, No Change Close, no change. The spec already allows putting private process in collaborations. ---------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 03/Feb/10 04:46 PM ] |
|
-------------------- Discussion during Converence call on 2010-02-03 -----------------------
Processes supporting interactions Processes are placed in an Collaboration, indicating support Are there any restictions? Collaboration can only use one Process Can put private processes in a collaboration--as long as the spec doesn't restrict this, then there is no issue. Action: Close; no change. The spec already allows putting private process in collaborations. |
| Comment by Stephen White [ 03/Feb/10 04:47 PM ] |
|
------------- New Proposed Resolution ----- 2010-02-03 -------------
Close, no change. The spec already allows putting private process in collaborations. --------------------------------------------------------------------------------------- |
[BPMNFTF-343] [OMG 14659] Correlation Class Diagram missing Process association
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-574 ##Original Info: (Severity: Significant - Nature: Revision) Figure 8-18 (The Correlation Class Diagram) is missing the association between CorrelationSubscription and Process that appears in Table 8-35 (CorrelationSubscription model associations). ##Proposed Resolution: Duplicate The resolution of this issue is covered by |
[BPMNFTF-342] [OMG 14658] Promote correlationKeys association to ConversationContainer
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-575 ##Original Info: (Severity: Significant - Nature: Revision) correlationKeys is on Conversation and Subconversation in Figure 8-18 (The Correlation Class Diagram). Promote it to ConversationContainer. ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:11 PM ] |
| New Proposed Resolution |
[BPMNFTF-341] [OMG 14652] Private process example correction
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMNFTF-341-private-process-example.pdf
|
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-581 ##Original Info: (Severity: Significant - Nature: Revision) The private process in Figure 10-122 (One Process supporting to another) should have activity X and event B in parallel, because event B may arrive while X is executing, which would be lost in the current example. See webinar example on slide 51 in bmi/09-06-02. -------------------- Proposal ----------- 2010-01-28 --------------------------------- ##Proposed Resolution: Fixed (a) Replace Figure 10.123 (One Process supporting to another) with the one given in the attachment http://www.osoa.org/jira/secure/attachment/10602/BPMNFTF-341-private-process-example.pdf. (b) In paragraph above Figure 10.123, next to last sentence (the one beginning "It also introduces"), replace "Activity" with "Activities". |
| Comments |
| Comment by Conrad Bock (NIST) [ 26/Jan/10 02:36 PM ] |
| See attached proposal. |
| Comment by Conrad Bock (NIST) [ 28/Jan/10 09:30 AM ] |
|
-------------------- Proposal ----------- 2010-01-28 ---------------------------------
##Proposed Resolution: Resolved Replace Figure 10.123 (One Process supporting to another) with the one given in the attachment http://www.osoa.org/jira/secure/attachment/10602/BPMNFTF-341-private-process-example.pdf. In paragraph above Figure 10.123, next to last sentence (the one beginning "It also introduces"), replace "Activity" with "Activities". |
| Comment by Stephen White [ 28/Jan/10 11:53 AM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-28 ----------------------------
see above comment |
[BPMNFTF-340] [OMG 14656] Gateways in Choreography missing split or merge
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-577 ##Original Info: (Severity: Significant - Nature: Revision) The section on gateways in choreography covers splits (diverging) gateways but not merges (converging) for parallel, exclusive. Only merges are covered for complex gateways. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 10:40 AM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
[BPMNFTF-339] [OMG 14657] CorrelationClassDiagram missing conversation association end name
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-576 ##Original Info: (Severity: Significant - Nature: Revision) Figure 8-18 (The Correlation Class Diagram) is missing the association end name listed in Table 8-32 (CorrelationKey model associations). ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 24/Jul/09 12:40 PM ] |
| I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32). |
| Comment by Stephen White [ 22/Mar/10 06:10 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:34 PM ] |
| Move it on ballot #11 to clarify the MM shown in the specification and related specification text. |
[BPMNFTF-338] [OMG 14653] Message flow to/from events in Collaboration diagrams
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-580 ##Original Info: (Severity: Significant - Nature: Revision) Send/receive events and tasks have the same meaning, but the Collaboration section only shows message flow to/from tasks and other activities. Clarify that message flow can be attached to send/receive events in Collaboration. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 10:40 AM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
[BPMNFTF-337] [OMG 14660] Conversation/Process switch
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
8_corestruct.doc
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-573 ##Original Info: (Severity: Significant - Nature: Revision) Section 8.3.3 (Correlation), first bullet says "dispatched to this particular Conversation". This should describe dispatching to a process instance, there are no conversation instances. Another example is in the CorrelationKey paragraph under Figure 8-18 (The Correlation Class Diagram). Might be other places in the spec refering to conversations as if they were executed. ##Proposed Resolution: Fixed Section 8.3.3 > Subsection "CorrelationKey", first paragraph Original For each Message that is received within a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which references a FormalExpression to the Message payload. Proposal For each Message that is exchanged as part of a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which references a FormalExpression to the Message payload. > Subsection "Key-based Correlation", first paragraph Original Messages will be routed to the Conversation whose extracted composite key matches the respective CorrelationKey instance. Proposal Messages are associated to a particular Conversation if the composite key extracted from their payload matches the CorrelationKey initialized for this Conversation. |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 11:20 PM ] |
|
As per March F2F Meeting:
- Need to be fixed as stated in the issue description. - This is an editorial issue. |
| Comment by Ivana Trickovic [ 22/Mar/10 06:04 PM ] |
| proposalScheduledForBallot11 |
| Comment by Karsten Ploesser (SAP) [ 11/Apr/10 09:01 PM ] |
|
This issue depends on issue |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:43 AM ] |
| Attached issue resolution proposal (MS Word) |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:46 AM ] |
|
Proposed resolution:
Section 8.3.3 > Subsection "CorrelationKey", first paragraph Original For each Message that is received within a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which references a FormalExpression to the Message payload. Proposal For each Message that is exchanged as part of a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which references a FormalExpression to the Message payload. > Subsection "Key-based Correlation", first paragraph Original Messages will be routed to the Conversation whose extracted composite key matches the respective CorrelationKey instance. Proposal Messages are associated to a particular Conversation if the composite key extracted from their payload matches the CorrelationKey initialized for this Conversation. |
| Comment by Karsten Ploesser (SAP) [ 12/Apr/10 12:46 AM ] |
| New Proposed Resolution |
[BPMNFTF-336] [OMG 14651] isImmediate default
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMNFTF-366-isImmediate-default-2.pdf
BPMNFTF-366-isImmediate-default.pdf
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-582 ##Original Info: (Severity: Significant - Nature: Revision) isImmediate on SequenceFlow currently defaults to true for all private processes. It should default to false for non-executable processes, because these are not intended to be completely specified. -------------------- Proposal ----------- 2010-02-10 --------------------------------- ##Proposed Resolution: Fixed In Table 8.60 (SequenceFlow attributes and model associations), isImmediate row: (a) Second bullet: Replace "a public Processes" with "non-executable Processes (public Processes and non-executable private Processes)" (b) Third bullet: Replace "an executable and non-executable (internal)" with "executable". In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes): Second bullet, replace the (c) Two occurrences of "processType" with "isExecutable". (d) First occurrence of "public" with "non-executable". (e) Second occurrence of "public" with "false, or defaults to false". (f) "private" with "executable". (g) "executable or non-executable" with "true, or defaults to true" (h) In XMI/XSD, change isImmediate attribute on SequenceFlow to be optional. ---------------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Conrad Bock (NIST) [ 26/Jan/10 02:05 PM ] |
| See attached slides with background and proposal. |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 10:20 AM ] |
|
Attached is an updated presentation with the proposal modified to work with the proposal for |
| Comment by Conrad Bock (NIST) [ 10/Feb/10 10:21 AM ] |
|
The following proposal is written to work with the proposal for
-------------------- Proposal ----------- 2010-02-10 --------------------------------- ##Proposed Resolution: Fixed In Table 8.60 (SequenceFlow attributes and model associations), isImmediate row: Second bullet: Replace "a public Processes" with "non-executable Processes (public Processes and non-executable private Processes)" Third bullet: Replace "an executable and non-executable (internal)" with "executable". In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes): Second bullet, replace the Two occurrences of "processType" with "isExecutable". First occurrence of "public" with "non-executable". Second occurrence of "public" with "false, or defaults to false". "private" with "executable". "executable or non-executable" with "true, or defaults to true" In XMI/XSD, change isImmediate attribute on SequenceFlow to be optional. |
| Comment by Gary Brown [ 10/Feb/10 11:33 AM ] |
|
Although I think your proposal is sensible, I'm concerned with whether users will actually remember the default values depending on the context. In that respect, it may be better to use a single default value regardless of the context - and have tools apply the appropriate initial value based on the type of process/choreography selected?
However, in terms of the actual 'isImmediate' mechanism, it would seem easier to move this to the 'supports' relationship - i.e. define a public process and then define a 'supports' relationship to the private executable process, with an attribute indicating that the executable process is 'open' - i.e. is free to extend the behaviour expressed in the public process. But I guess it may be too late to make this type of change - its just the current approach seems too fine grained. |
[BPMNFTF-335] [OMG 14655] Complex gateway merging rule in choreography too restrictive
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-578 ##Original Info: (Severity: Significant - Nature: Revision) Section 12.7.3 Inclusive Gateway (pg 344 / 375 pdf) The rule fo merging complex gateway in choreography is "In order to enforce the synchronizing merge of the Gateway, the senders or receivers Choreography Activities preceding the Gateway need to be the same Participant. This ensures that the merge can be enforced." but if the sender of the activity after the gateway participates in the activties before the gateway, and has access to the complex decision data, then it has everything needed to perform the synchronization. |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:02 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:32 AM ] |
|
-----Original Message----- From: Bock, Conrad Sent: Saturday, March 20, 2010 7:20 PM To: 'Trickovic, Ivana' Cc: 'Mariano Benitez (Oracle) (JIRA)'; 'Stephen A White' Subject: RE: [BPMN 2.0 FTF] Ballot 9 Ready for review Mariano, > Yes, there was a confusion, it's all settled. Please send Ivana > (again) the list of issues to remove from Ballot 9. Thanks, sorry again for the extra time spent reviewing them. Ivana, Here are the issue I had intended to assign myself: http://www.osoa.org/jira/browse/BPMNFTF-335 http://www.osoa.org/jira/browse/BPMNFTF-378 http://www.osoa.org/jira/browse/BPMNFTF-347 http://www.osoa.org/jira/browse/BPMNFTF-389 http://www.osoa.org/jira/browse/BPMNFTF-379 Thanks for accommodating, Conrad ----------Original Message---------- From: "Bock, Conrad" <conrad.bock@nist.gov> Sent: Fri, March 19, 2010 10:26 AM To: "bpmn2-ftf@omg.org" <bpmn2-ftf@omg.org> Mariano, > It is the solely purpose of ballots for everyone to express > their agreement / disagreement. What we do honor is the > time people has taken to analyze the issues and make a > proposal. So we do not remove issues from ballots unless > there are counterproposals or commitment from other people > to write one. Sorry for any time spent on these, I'm committing to write the resolutions on the ones below. Steve said there was some confusion about the interaction issues, so I hadn't completed going through them for the assignments. (The last one isn't an interaction issue, but almost editorial, I'd like to fix it to avoid confusion about semantics) Thx, Conrad -----Original Message----- From: Bock, Conrad Sent: Wednesday, March 17, 2010 11:22 AM To: 'bpmn2-ftf@omg.org' > Ballot 9 is scheduled to open on 2010-03-23. Please review the issues > before this date. I assigned these to myself, sorry I hadn't gone through the interaction issues, thought they were waiting on the C-merge. These can be removed from the ballot: http://www.osoa.org/jira/browse/BPMNFTF-335 http://www.osoa.org/jira/browse/BPMNFTF-378 http://www.osoa.org/jira/browse/BPMNFTF-347 http://www.osoa.org/jira/browse/BPMNFTF-389 http://www.osoa.org/jira/browse/BPMNFTF-379 Conrad |
| Comment by Conrad Bock (NIST) [ 11/Apr/10 01:48 PM ] |
|
-----------Proposal----------------Apr 11, 2010---------------------------
##Proposed Resolution: Fixed The quote in the issue is from the inclusive gateway, rather than the complex merge. In the Choreography chapter, in section Gateways, subsection Inclusive Gateway, under the third paragraph, first bullet, second subbullet (the one beginning "Merge:"), in the sentence immediately after the colon (the one beginning "In order to enforce"), replace the portion of the sentence after the comma with: the sender of the Choreography Activity after the Gateway must participate in the Choreography Activities immediately preceding the gateway. In the Choreography chapter, in section Gateways, subsection Inclusive Gateway, in the paragraph just above the first figure, third sentence, replace the portion of the sentence after the comma with: the initiator of Choreography Activities immediately following the Gateway participates in the Choreography Activities immediately preceding the Gateway. |
[BPMNFTF-334] [OMG 14654] Beta 1 Section 11 Conversation: The concepts of Conversation, Conversation Diagram, and Communication are too confusing.
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
C-Merge Docs - Issue 334.zip
c-merge-2.pdf
c-merge-3.pdf
c-merge.pdf
Revised BPMN Terms.jpg
Semantic.xsd
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-579 ##Original Info: (Severity: Critical - Nature: Revision) The distinctions between Conversation and Communication are not clear. It appears as though the Conversation is used for multiple concepts, including a diagram. This should be clarified. ##Proposed Resolution: Fixed The proposal is to merge the Collaboration and Conversation diagrams. While the proposal is complicated it will: - Significantly simplify implementation by reducing the number of metamodel elements, metamodel complexity, and required text restriction - Provides a better alignment with another standard: SoaML - There would be no loss of current end-user functionality The Proposal includes: (a) Delete Chapter 11. It's contents will be moved to Chapter 9 as detailed below Modifications to Section 8 (b) Section 8, page 39 (69 pdf), last paragraph: change "Choreography, Collaboration, and Conversation" to "Choreography, and Collaboration" (c) Figure 8.3, replace figure with new organization of Core elements (see Specification Convenience Document) (d) Section 8.3, page 55 (85 pdf), first sentence: change "Collaboration, Conversation, and Choreography" to "Collaboration, and Choreography" (f) Figure 8.8, replace figure with new organization of Artifact elements (see Specification Convenience Document) (g) Section 8.3.2, page 63 (93 pdf), replace first sentence with: "CallableElement is the abstract super class of all elements that have been defined outside of a Process, but which can be called (or reused), by a Call Activity, from within a Process." (h) Section 8.3.2, page 63 (93 pdf), add at the end of the first paragraph: "The BPMN elements that can be called by Call Activities (i.e., are Callable Elements) are: Process and GlobalTask (see Figure 8.17)." (i) Figure 8.17, replace figure with new organization of Callable elements (see Specification Convenience Document) (j) Move Section 8.3.2 to a subsection of Section 10.2.6 (k) Section 8.3.3, page 65 (95 pdf), change first sentence to: "The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task, often in the context of a Conversation, which is also known as instance routing." (l) Section 8.3.3, page 65 (95 pdf), second sentence: change "Conversation, Choreography" to "Collaboration (Conversation), Choreography" (m) Figure 8.18, replace figure with new organization of Correlation elements (see Specification Convenience Document) (n) Table 8.32, CorrelationKey: delete the row for the conversation attribute (o) Section 8.3.4, page 71 (101 pdf), replace first paragraph with "These elements are used to do mapping between two elements that both contain Conversation Nodes. The ConverstaqionAssociation provides the mechanism to match up the Conversation Nodes." (p) Section 8.3.4, page 71 (101 pdf), second paragraph, delete second sentence (q) Section 8.3.4, page 71 (101 pdf), replace first bullet on page with: "A Collaboration references a Choreography for inclusion between the Collaboration's Pools (Participants). The Conversation Nodes of the Choreography (the inner diagram) need to be mapped to the Conversation Nodes of the Collaboration (the outer diagram)." (r) Section 8.3.4, page 71 (101 pdf), delete second bullet on page (s) Figure 8.18, replace figure with new organization of Conversation elements (see Specification Convenience Document) (t) Table 8.42, page 72 (102 pdf), delete first row of table (u) Table 8.42, page 72 (102 pdf), replace first column of second row with: "innerConversationNodeRef: ConversationNode" (v) Table 8.42, page 72 (102 pdf), replace second column of second row with: "This attribute defines the Conversation Nodes of the referenced element (e.g., a Choreography to be used in a Collaboration) that will be mapped to the parent element (e.g., the Collaboration)." (w) Table 8.42, page 72 (102 pdf), replace first column of third row with: "outerConversationNodeRef: ConversationNode" (x) Table 8.42, page 72 (102 pdf), replace second column of third row with: "This attribute defines the Conversation Nodes of the parent element (e.g., a Collaboration references a Choreography) that will be mapped to the referenced element (e.g., the Choreography)." (y) Move Section 8.3.4 to Section 11 after Section 11.7. The Contents of Section 11 will be moved to Section 9 as described below. (z) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document) (a2) Table 8.46: delete second row (artifacts attribute) (b2) Delete section 8.3.11, Interaction Specification. All Interaction Specification characters have been moved to Collaboration (Section 9 and detailed below) (c2) Section 8.3.14, page 87 (117 pdf), first paragraph (non-bullet): delete "(the view showing the Choreography Process Combined with Orchestration Processes)" from first sentence. (d2) Section 8.3.14, page 88 (118 pdf), first paragraph : Change "Choreography Task" to "Choreography" (e2) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document) (f2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf), second paragraph: Delete second sentence (g2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf): Delete the second and third bullet on the page. (h2) Figure 8.39, replace figure with new organization of Message Flow Association elements (see Specification Convenience Document) (i2) Move Section 8.3.14 to Section 9 and make it Section 9.3 (j2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "InteractionSpecification" to "Collaboration" (k2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "Collaboration, a Choreography, a Conversation, a Global Communication, or a GlobalChoreographyTask" to "Choreography, GlobalConversation, or GlobalChoreographyTask" (l2) Figure 8.40, replace figure with new organization of Participant elements (see Specification Convenience Document) (m2) Section 8.3.15, Sub-Section Participant Multiplicity, second paragraph: Change "Choreography" to "Collaboration" (n2) Section 8.3.15, Sub-Section Participant Association, second paragraph: Change "three (3)" to "four (4)" (o2) Section 8.3.15, Sub-Section Participant Association: replace the second bullet with the following: "A CallConversation references a Collaboration or GlobalConversation. Thus, the Participants of the Collaboration or GlobalConversation (the inner diagram) need to be mapped to the Participants referenced by the CallConversation (the outer element). Each CallConversation contains its own set of ParticipantAssociations." (p2) Section 8.3.15, Sub-Section Participant Association: replace the third bullet with the following: "A CallChoreography references a Choreography or GlobalChoreographyTask. Thus, the Participants of the Choreography or GlobalChoreographyTask (the inner diagram) need to be mapped to the Participants referenced by the CallChoreography (the outer element). Each CallChoreography contains its own set of ParticipantAssociations." (q2) Section 8.3.15, Sub-Section Participant Association: add a forth bullet with the following: "A CallActivity within a Process that has a definitional Collaboration references another Process that also has a definitional Collaboration. The Participants of the definitional Collaboration of the called Process (the inner diagram) need to be mapped to the Participants of the definitional Collaboration of the calling Process (the outer diagram)." (r2) Figure 8.43, replace figure with new organization of Participant Association elements (see Specification Convenience Document) (s2) Move Section 8.3.15 to Section 9 and make it Section 9.2.1 (t2) Move Table 8.62 to Section 10.2.9 (u2) Table 8.63, replace the "extension" section of the table with the following: "<xsd:extension base="tBaseElement"> <xsd:sequence> <xsd:element name="innerConversationNodeRef" type="xsd:QName"/> <xsd:element name="outerConversationNodeRef" type="xsd:QName"/> </xsd:sequence> </xsd:extension>" (v2) Move Tables 8.63, 8.72, 8.73, 8.74, 8.75, 8.76, and 8.77 to Section 9.5 Collaboration Package XML Schemas Modifications to Section 7 (w2) Section 7.1.1, Sub-Section Conversations, first paragraph, first sentence: change "The Conversation diagram is similar to a Collaboration diagram" to "The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram" (x2) Section 7.1.1, Sub-Section Conversations, first paragraph, second sentence: change "Pools of a Conversation are not allowed to contain a Process and a Choreography is not allowed to be placed in between the Pools" to "Pools of a Conversation are usually do not contain a Process and a Choreography is usually not placed in between the Pools" (y2) Section 7.1.1, Sub-Section Conversations, second paragraph: change "Communication" to "Conversation" Modifications to Section 9 (z2) Section 9, second paragraph: after the first sentence add the following sentence: "A Choreography is an extended type of Collaboration." (a3) Figure 9.1, replace figure with new organization of Collaboration elements (see Specification Convenience Document) (b3) Section 9, paragraph before Table 9.1: delete ", and InteractionSpecification (see Table 8.48)" (c3) Table 9.1: add row to top of table with "name: string [0..1]" in the first column and "The descriptive name of the Collaboration." in the second column. (d3) Table 9.1, choreographyRef attribute row: replace the second column with the following: "The choreographyRef model association defines a Choreography that is shown between the Pools of the Collaboration. A Choreography specifies a business contract (or the order in which messages will be exchanged) between interacting Participants. See page 327 for more details on Choreography. The participantAssociations (see below) are used to map the Participants of the Choreography to the Participants of the Collaboration. The MessageFlowAssociations (see below) are used to map the Message Flows of the Choreography to the Message Flows of the Collaboration. The ConversationAssociations (see below) are used to map the Conversations of the Choreography to the Conversations of the Collaboration. Note that this attribute is not applicable for Choreography or GlobalConversation which are a subtypes of Collaboration. Thus, a Choreography cannot reference another Choreography." (e3) Table 9.1: add row after ChoreographyRef attribute row with "correlationKey: CorrelationKey [0..*]" in the first column and "This association specifies correlationKeys used to associate Messages to a particular Collaboration." in the second column. (f3) Table 9.1, conversationAssociations attribute row: replace the second column with the following: "This attribute provides a list of mappings from the Conversations of a referenced Collaboration to the Conversations of another Collaboration. It is used when: • When a Choreography is referenced by a Collaboration." (g3) Table 9.1, conversations attribute row: replace "Conversation" with "ConversationNode" (h3) Table 9.1, conversations attribute row: replace the second column with the following: "The conversations model aggregation relationship allows a Collaboration to contain Conversation elements, in order to group Message Flow of the Collaboration and associate correlation information, as is required for the definitional Collaboration of a Process model. The Conversation elements will be visualized if the Collaboration is a Collaboration, but not for a Choreography." (i3) Table 9.1: add row after artifacts attribute row with "participants: Participant [0..*]" in the first column and "This provides the list of Participants that are used in the Collaboration. Participants are visualized as Pools in Collaboration and as Participant Bands in Choreography Activities for Choreography." in the second column. (j3) Table 9.1, participantAssociations attribute row: replace the second column with the following: "This attribute provides a list of mappings from the Participants of a referenced Collaboration to the Participants of another Collaboration. It is used in the following situations: • When a Choreography is referenced by a Collaboration. • When a definitional Collaboration for a Process is referenced through a CallActivity (and mapped to definitional Collaboration of the calling Process)." (l3) Table 9.1: add row after participantAssociations attribute row with "messageFlow: Message Flow [0..*]" in the first column and "This provides the list of Message Flow that are used in the Collaboration. Message Flow are visualized in Collaboration (as dashed line) and hidden in Choreography." in the second column. (m3) Table 9.1, messageFlowAssociations attribute row: replace the second column with the following: "This attribute provides a list of mappings for the Message Flow of the Collaboration to Message Flow of a referenced model. It is used in the following situations: • When a Choreography is referenced by a Collaboration. This allows the "wiring up" of the Collaboration Message Flow to the appropriate Choreography Activities." (n3) Section 9, after Table 9.1: split first paragraph into two paragraphs after the first sentence (o3) Section 9, after Table 9.1: replace the first sentence of the newly created paragraph (the second paragraph) with the following: "Correlations are the mechanism that is used to assign the Messages to the proper Process instance, and can be defined for the Message Flow that belong to a Conversation." (p3) Move the text from the newly created paragraph until the end of the section (stopping at Section 9.1) to a new section (to be created) and label that section "9.4.8 Correlations" (q3) Section 9.2, first paragraph, first sentence: delete "or a Choreography" (r3) Section 9.3: Change title of section to "Process within Collaboration" (s3) Figure 9.8, replace figure with new organization of Choreography and Collaboration elements (see Specification Convenience Document) (t3) Table 9.2, Collaboration XML Schema: Change "<xsd:element ref="conversation"" to "<xsd:element ref="conversationNode"" (u3) Table 9.2, Collaboration XML Schema: add the following to the <xsd:sequence> section: "<xsd:element ref="correlationKey" minOccurs="0" maxOccurs="unbounded"/>" Modifications to Section 10 (v3) Figure 10.2, replace figure with new organization of Process detail elements (see Specification Convenience Document) (w3) Table 10.3: add row after laneSets attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are contained within the Process." in the second column. (x3) Figure 10.28, replace figure with new organization of Sub-Process elements (see Specification Convenience Document) (y3) Table 10.3: add row after triggeredByEvent attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are contained within the Sub-Process." in the second column. Modifications to Section 11 (z3) Section 11: Replace "Communication" with "Conversation" throughout section (a4) Section 11: Replace "GlobalCommunication" with "GlobalConversation" throughout section (b4) Section 11: Replace "CommunicationLink" with "ConversationLink" throughout section (c4) Section 11: replace first paragraph with the following: "The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram. In general, it is a simplified version of Collaboration, but Conversation diagrams do maintain all the features of a Collaboration." (d4)Section 11: replace first bullet in section with the following: "Conversation Node elements (Conversation, Sub-Conversation, and Call Conversation)" (e4) Section 11, first sentence after second bullet: replace sentence with the following: "A Conversation is a logical grouping of Message exchanges (Message Flow) that can share a Correlation." (f4) Section 11, first paragraph after Figure 11.1: add the following to the end of the paragraph: "Note that the diagram looks the same as a simple Collaboration diagram (as in Figure 9.3, above)." (g4) Section 11, second paragraph after Figure 11.2: add the following to the end of the sentence: ", but the Conversations are not visualized in a Choreography" (h4) Section 11, third paragraph after Figure 11.2, first sentence: replace "Choreography" with "Collaboration" (i4) Section 11: delete Figure 11.5 and the paragraph above it. (j4) Section 11: delete Table 11.1, the paragraph above it and the paragraph below it. (k4) Delete Section 11.1 (l4) Section 11.2, first paragraph: replace "all elements that can appear in a Conversation diagram" with "all elements that comprise the Conversation elements of a Collaboration diagram" (m4) Section 11.2: add figure after first paragraph with the title: "Metamodel of ConversationNode Related Elements" (see Specification Convenience Document) (n4) Table 11.3: add row with "messageFlowRefs: MessageFlow [0..*]" in the first column and "A reference to all Message Flows (and consequently Messages) grouped by a Conversation element." in the second column. (o4) Table 11.3 : add row with "correlationKeys: CorrelationKey [0..*]" in the first column and "This is a list of the ConversationNode's correlationKeys, which are used to group Message Flows for the ConversationNode." in the second column. (p4) Section 11.3, first sentence: change "Conversation diagram" to "Conversation (Collaboration) diagram" (q4) Section 11.3. second sentence: replace "single" with "concept and/or a" (r4) Section 11.3, first paragraph before Table 11.4: Delete second sentence and add the following to the end of the first sentence: "but does not contain any additional attributes or model associations" (s4) Delete Table 11.4 (t4) Section 11.4, first paragraph, first sentence: replace "parent Conversation" with "parent Collaboration" (u4) Section 11.4, first paragraph, second sentence: replace "within a Conversation" with "within a Collaboration" (v4) Table 11.5: replace the first column of the first row with the following: "conversationNodes: ConversationNode [0..*]" (w4) Table 11.5: replace the second column of the first row with the following: "The ConversationNodes model aggregation relationship allows a Sub-Conversation to contain other ConversationNodes, in order to group Message Flow of the Sub-Conversation and associate correlation information." (x4) Section 11.5, first sentence: change "in the Conversation" to " in the Conversation (Collaboration)" (y4) Section 11.5, second bullet: change "calls a Conversation" to "calls a Collaboration" (z4) Table 11.6, first row, first column: change "calledElementRef" to "calledCollaborationRef" and change "CallableElement" to "Collaboration" (a5) Table 11.6, first row: replace second column with the following: "The element to be called, which MAY be either a Collaboration or a GlobalConversation. The called element MUST NOT be a Choreography or a GlobalChoreographyTask (which are subtypes of Collaboration)" (b5) Section 11.5: add the following after Table 11.6: "Note - The ConversationNode attribute messageFlowRef doesn't apply to Call Conversations." (c5) Section 11.6, first sentence: Change "within any Conversation" to "within any Collaboration" (d5) Section 11.6: Replace the second paragraph with the following: "The GlobalConversation element inherits the attributes and model associations of Collaboration (see Table 8.48), but does not have any additional attributes or model associations. A GlobalConversation is a restricted type of Collaboration, it is an "empty Collaboration." [diamond bullet] A GlobalConversation MUST NOT contain any ConversationNodes. Since a GlobalConversation does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or ConversationFlowAssociations or Artifacts. It is basically a set of Participants, Message Flows , and correlationKeys intended for reuse. Also, the Collaboration attribute choreographyRef is not applicable to GlobalConversation." (e5) Delete Table 11.7 (f5) Move all tables in Section 11.8 (XML Schemas) to Section 9.5 (g5) Move all remaining contents of Section 11 to Section 9.4 and name that section "Conversations" Modifications to Section 12 (h5) Replace "Choreography Sub-Process" with "Sub-Choreography" throughout section (i5) Figure 12.1, replace figure with new organization of Choreography elements (see Specification Convenience Document) (j5) Section 12.1, first paragraph after Figure 12.1: replace "CallableElement" with "Collaboration" (k5) Section 12.1, first paragraph after Figure 12.1: Delete the second sentence and add the following to the end of the first sentence: ", but does not have any additional attributes or model associations. (l5) Delete Table 12.1 (m5) Add the following paragraph to the end of the section (before Section 12.1): "Note - The Collaboration attribute choreographyRef is not applicable to Choreography." (n5) Section 12.3.1, page 313 (343 pdf), last bullet on page, first sentence: replace "the isClosed attribute of a Choreography" with "the isClosed attribute (from Collaboration)" (o5) Figure 12.6: replace figure with new organization of Choreography Activity elements (see Specification Convenience Document) (p5) Section 12.4.2, last paragraph in section (before Section 12.4.3): replace the second sentence with the following: "Table 12.X presents the additional model associations of the Sub-Choreography element" (q5) Section 12.4.2, after last paragraph in section: Add a table entitled "Sub-Choreography Model Associations" with one row, with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are contained within the Sub-Choreography." in the second column (r5) Replace "Call Choreography Activity" with "Call Choreography" throughout section (s5) Figure 12.27, replace figure with new organization of Call Choreography elements (see Specification Convenience Document) (t5) Table 12.4, first row, first column: change "calledElementRef" to "calledChoreographyRef" and change "CallableElement" to "Choreography" (u5) Table 12.4, first row, second column: delete second sentence of column (v5) Table 12.4, second row, second column: change "containing" to "referenced by" (w5) Section 12.4.4, second paragraph, first sentence: Change "CallableElement" to "Collaboration" and add the following to the end of the sentence: "through its relationship to Choreography" (x5) Section 12.4.4: add the following after Table 12.5: "A GlobalChoreographyTask is a restricted type of Choreography, it is an "empty Choreography." [diamond bullet] A GlobalChoreographyTask MUST NOT contain any Flow Elements. Since a GlobalChoreographyTask does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or ConversationFlowAssociations or Artifacts. It is basically a set of Participants and Message Flows intended for reuse." (y5) Table 12.9: change "substitutionGroup="rootelement"" to "substitutionGroup="collaboration"" (z5) Table 12.9: change "base="tCallableElement"" to "base="tCollaboration"" (a6) Table 12.9: delete the following: "<xsd:element ref="artifact" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="conversation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="conversationAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="messageFlowAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="participantAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:attribute name="isClosed" type="xsd:boolean" default="false"/>" (b6) Table 12.10: change "substitutionGroup="rootelement"" to "substitutionGroup="choreography"" (c6) Table 12.10: change "base="tCallableElement"" to "base="tChoreography"" (d6) Table 12.10: delete the following: "<xsd:sequence> <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence>" (e6) Table 12.13: change "calledElement" to "calledChoreographyRef" |
| Comments |
| Comment by Stephen White [ 11/Jan/10 07:50 PM ] |
|
----------------------- New Proposed Resolution -------- 2010-01-11 ---------------------
Change all occurrences of "Communication" to "Conversation" Change all occurrences of "Sub-Conversation" to "Nested Conversation" Change all occurrences of "Global Communication" to "Global Conversation" Change all occurrences of "Conversation" to "Conversation Diagram" [Note that this is likely to be removed by Issue 308] "Conversation Node" remains The Call Conversation can only call a Global Communication. It cannot call a Conversation Diagram, which will be removed by Issue 308, or replaced by the Collaboration Diagram (because of Issue 308) The Global Conversation element will be given a calledElementRef association to call other Conversation, thus creating re-usable Nested Conversation. If nested, the Call Conversation will display the plus sign. A Conversation (Atomic) will be able to contain multiple correlationKeys--change the multiplicity from 0..1 to * ------------------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 12/Jan/10 09:17 PM ] |
| New Proposed Resolution: Fixed |
| Comment by Conrad Bock (NIST) [ 21/Jan/10 01:05 PM ] |
| c-merge.pdf attachment is about reuse/nesting of merged collaboration/conversation diagrams. |
| Comment by Conrad Bock (NIST) [ 22/Jan/10 11:02 AM ] |
|
From soaML discussion: diagram that merges existing collaboration and
conversation diagrams should support processes appearing in participants (like current collaboration diagrams) at the same time as showing conversations (as octogons, like current conversation disagrams). Conversation links (lines from octogons) should be able to link to activities in processes in participants. |
| Comment by Conrad Bock (NIST) [ 25/Jan/10 02:29 PM ] |
| Update to previous "c-merge" document, including metamodels. |
| Comment by Conrad Bock (NIST) [ 28/Jan/10 04:51 PM ] |
| Updated c-merge slides from subgroup input today. |
| Comment by Stephen White [ 18/Mar/10 08:23 PM ] |
| proposalScheduledForBallot10 |
| Comment by Stephen White [ 26/Mar/10 06:58 PM ] |
| New Proposed Resolution |
| Comment by Denis Gagne [ 13/May/10 09:58 AM ] |
|
Spec-Draft3-review
Title of section 9.4.5 should be renamed Global Conversation |
| Comment by Ivana Trickovic [ 17/May/10 03:27 PM ] |
| As per the meeting of May 17th: Agreed that this needs to b fixed |
| Comment by Stephen White [ 18/May/10 04:18 PM ] |
| Done |
[BPMNFTF-333] [OMG 14650] Subprocess / CallActivity switch
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Meera Srinivasan (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-583 ##Original Info: (Severity: Significant - Nature: Revision) Section 10.4.2 (Start Event) uses the BPMN 1.x term "subprocess" to include called processes. In BPMN 2 "subprocess" means embedded. See Table 10-78 (Sub-Process Start Event Types) and under the heading "Start Event Triggers". Might be in other places also. ##Proposed Resolution: Fixed (a) Section 13.2.5, Sub-Section CalledSubProcessShape, Page 383 (412 pdf): Replace the first paragraph with the following: "A Call Activity is used for invoking a global Process. It has the same symbol as the subprocess (embedded). Expanding the Call Activity should display the called Process." (b) Table 13.13 - CalledSubProcessShape , first row, second column: replace contents of column with the following: "A reference to another BPMN diagram defining the details of the called Global Process. " (c) Table 13.13 - CalledSubProcessShape styles: , first row, second column: replace contents of column with the following: "Indicates whether the Call Activity is expanded or collapsed." Section 10.4.2 Start Event (d) First bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace "or an expanded Sub-Process" with ", a Sub-Process (embedded), or a Global Process (called Process)" (e) First paragraph after first bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace the first sentence of the paragraph with the following: "Note - A Process may have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes)." (f) Page 215 (245 pdf), First paragraph after the bullets: Replace the paragraph with the following: "If the Process is used as a Global Process (callable Process that can be invoke from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the Global Process (child Process), only one of the Global Process's Start Events will be triggered. The TargetRef attribute of the Sequence Flow incoming to the Global Process object can be extended to identify the appropriate Start Event." Sub-Section Start Event Triggers, page 215 (245 pdf) (g) Second bullet: delete " and called (reusable)" (h) Add new bullet after second bullet with the following: "Global Processes (called) (i) Sub-Section Start Events for Top-level Processes: add new paragraph after the first paragraph with the following: "A top-level that has at least one (1) None Start Event MAY be called by a Call Activity in another Process. The None Start Event is used for invoking the Process from the Call Activity. All other types of Start Events are only applicable when the Process is used as a top-level Process." Section 10.4.3 End Event (j) Page 222 (252 pdf), second bullet on page: delete "top-level" from first sentence. (k) Page 222 (252 pdf), first paragraph after bullets: replace first sentence of the paragraph with the following: "Note - A Process may have more than one Process level (i.e., it can include Expanded Sub-Processes or a Call Activities that call other Processes)." |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 06:59 AM ] |
|
proposalScheduledForBallot10
Meera is helping with these issues |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 10:40 AM ] |
|
Following places need to be updated to reflect this:
(1) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 383 Original Text: CalledSubProcessShape A Sub-Process is a compound Activity that is included within a Process (see page 176). It is compound in that it can be broken down into a finer level of detail (a Process through a set of sub-Activities). Replacement Text: [ Here we are referring to a Call Activity and not a Sub-Process though semantics for the two are similar] A Call Activity is used for invoking a global Process. It has the same symbol as the subprocess (embedded). Expanding the Call Activity should display the called Process. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:01 AM ] |
|
(2) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 384 (a) Table 13.13 - CalledSubProcessShape styles Original Text : A reference to another BPMN diagram defining the details of the Subprocess. Replacement Text: A reference to another BPMN diagram defining the details of the called Global Process. (b) Table 13.13 - CalledSubProcessShape styles Original Text : Indicated whether the Subprocess is expanded or collapsed. Replacement Text: Indicates whether the Call Activity is expanded or collapsed. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:12 AM ] |
|
(3) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 214 (a) Just below Figure 10.67 Start Event Original Text Semantics of the Start Event include: A Start Event is OPTIONAL: a Process level—a top-level Process or an expanded Sub-Process—MAY (is no required to) have a Start Event. Replacement Text Semantics of the Start Event include: A Start Event is OPTIONAL: a Process level - a top-level Process or Sub-Process (embedded) or a Global Process (called Process) - MAY (is not required) have a Start Event (b) Original Text Note - A Process may have more than one Process level (i.e., it can include Expanded Sub-Processes). The use of Start and End Events is independent for each level of the Diagram. Replacement Text Note - A Process may have more than one Process level (Using Call Activity to invoke another Global Process - callable Process, you can create a multi-level process or Process Hierarchy ). The use of Start and End Events is independent for each level of the Diagram. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:22 AM ] |
|
(4) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 215 Original Text: If the Process is used as a Sub-Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the Sub-Process, only one of the Sub-Process's Start Events will be triggered. The TargetRef attribute of the Sequence Flow incoming to the Sub-Process object can be extended to identify the appropriate Start Event. Replacement Text: If the Process is used as a Global Process (callable Process that can be invoke from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the Global Process (child Process), only one of the Global Process's Start Events will be triggered. The TargetRef attribute of the Sequence Flow incoming to the Global Process object can be extended to identify the appropriate Start Event. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:25 AM ] |
|
(5) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 215 Section: Start Event Triggers Original Text: Start Events can be used for three types of Processes: • Top-level Processes • Sub-Processes (embedded and called (reusable)) • Event Sub-Processes Replacement Text: Start Events can be used for four types of Processes: • Top-level Processes • Sub-Processes (embedded) * Global Processes (callable and reusable) • Event Sub-Processes |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:30 AM ] |
|
(6) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 215 Section: Start Events for Global Processes (callable and reusable) Original Text: [This is not addressed]. Replacement Text: The types of Start Events for a Global Process (callable & reusable) is the same as the top-level Process. The None Start Event is used for invoking the Global Process from the Call Activity of the Parent Process. All other types of Start Events are applicable when the Global Process is itself a top-level process. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:47 AM ] |
|
(6) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 221 Section: Sequence Flow Connections Original Text An exception to this is when a Start Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process. Replacement Text: An exception to this is when a Start Event is used in a Global Process (callable, reusable) and the Global Process is in turn attached to the boundary of Sub-Process (embedded). In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process (embedded). |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:51 AM ] |
|
(7) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 222 Below Figure 10.68 - End Event Original Text An End Event is OPTIONAL: a given Process level—a top-level Process or an expanded Sub-Process—MAY (is not required to) have this shape: Replacement Text: An End Event is OPTIONAL: a given Process level—a top-level Process or a Global Process (callable, reusable) or a Sub-Process (embedded) —MAY (is not required to) have this shape: |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:54 AM ] |
|
(8) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009
Page 222 Below Figure 10.68 - End Event Original Text Note - A Process may have more than one Process level (i.e., it can include Expanded Sub-Processes). The use of Start and End Events is independent for each level of the Diagram. Replacement Text Note - A Process may have more than one Process level (Using Call Activity to invoke another Global Process - callable Process, you can create a multi-level process or Process Hierarchy ). The use of Start and End Events is independent for each level of the Diagram. |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 11:58 AM ] |
|
(8) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 225 Original Text An exception to this is when an End Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect from that End Event in lieu of connecting from the actual boundary of the Sub-Process (see [-->REF]). Replacement Text An exception to this is when an End Event is used in a Global Process (callable, reusable) and the Global Process is in turn attached to the boundary of Sub-Process (embedded). In this case, a Sequence Flow from the higher-level Process MAY connect from that End Event in lieu of connecting to the actual boundary of the Sub-Process (embedded). |
| Comment by Stephen White [ 29/Mar/10 10:00 PM ] |
|
I replace the proposal for Item (3) (b) above with the following replacement text:
"Note - A Process may have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities). The use of Start and End Events is independent for each level of the Diagram." |
| Comment by Stephen White [ 11/Apr/10 01:49 PM ] |
| Some of the changes were modified from the attached comments and a couple of them were not used. |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 01:15 PM ] |
|
Spec-Draft3-review
items a), b), c) from section 13 do not appear in the final draft, since the entire section 13 was moved, and the concepts for not appear anymore. |
| Comment by Ivana Trickovic [ 17/May/10 03:26 PM ] |
|
As per the meeting of May 17th: Steve to add a comment that the issue resolution has been modified by another issue resolution ( |
| Comment by Stephen White [ 18/May/10 04:17 PM ] |
| Done |
[BPMNFTF-332] [OMG 14649] Key-based Correlation => ?
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Info: (Severity: Significant - Nature: Revision) Key-based correlation could have a better name, because context-based correlation (subscription) also uses keys, it just enables values for process keys to change over time. Perhaps the term could be "static correlation", meaning the values of process properties do not change over time (though values and keys can be added). BTW, "context-based" for subscription is equally vague. How about static vs dynamic correlation? |
| Comments |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 09:44 AM ] |
|
Matthias,
Was going to close this based on your telecon comment that context-based correlation does not need to use keys. But the spec currently says: Context-based correlation is a more expressive form of correlation on top of key-based correlation. and goes on to describe how correlation keys are used in context-based correlation. This means context-based correlation is also key-based, and the issue is suggesting the terminology doesn't reflect this. I don't mind deferring this for more discussion, but don't think we can close it. Conrad |
| Comment by Tammo van Lessen [ 26/Mar/10 11:26 AM ] |
| FYI: http://eprints.qut.edu.au/5695/ is the paper I was talking about. It refers to BPMN's "key-based correlation" as "key-based correlation" and to BPMN's "context-based correlation" as "property-based correlation". cf p.7, C1 and C2. May be that's of help to close or work on this issue. |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 01:52 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 08/Apr/10 04:07 PM ] |
|
-----------Proposal----------------Apr 8, 2010---------------------------
##Proposed Resolution: Closed, No Change The terms "key-based" and "context-based" are common in the area of correlation, it's best to leave them as they are. |
[BPMNFTF-331] [OMG 14834] Order of outgoing sequence flows from exclusive gateway
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock conrad.bock@nist.gov)
Specification: BPMN 2 Beta 1 Section: Process FormalNumber: dtc/09-08-14 Version: RevisionDate: Page: Title: Order of outgoing sequence flows from exclusive gateway Nature: Revision Severity: Significant Description: Metamodel does not capture order of outgoing sequence flow from exclusive gateway, which is needed to evaluate the conditions in order, per Table 14.2. -------------------- Proposal ---------- 2010-01-26 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14753 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 04/Dec/09 10:11 AM ] |
| I assume the issue description meant "sequence flow" rather than "message flow". Is correct in the title. |
| Comment by Stephen White [ 04/Dec/09 01:26 PM ] |
| Corrected description to say sequence flow instead of message flow. But the OMG data base will retain the original wording. |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 12:31 PM ] |
|
Duplicate of |
| Comment by Mariano Benitez (Oracle) [ 26/Jan/10 05:24 PM ] |
|
New Proposed Resolution: Duplicate
Just putting Suzette's proposal in format. |
[BPMNFTF-330] [OMG 14833] Called conversations without keys of the caller
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: NIST (Conrad Bock conrad.bock@nist.gov)
******************************************************************************* Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: BPMN 2 Beta 1 Section: Conversations FormalNumber: dtc/09-08-14 Version: RevisionDate: Page: Title: Called conversations without keys of the caller Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Called conversations might have messages that don't have the correlation keys of the caller. Clarify whether this is allowed or not. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 06:07 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 23/Mar/10 01:50 PM ] |
|
-------------- Interactions Conference Call on 2010-03-23 --------------------------
To address this issue, the definition of how CorrelationKeys are stacked through different levels of Conversation needs to be added to spec. Sections 9.4.1, 9.4.3, and 9.4.8 need updating. Stacking means that lower-level Conversation Messages must contain keys for that level and any higher level, including the Collaboration. For CallConversations--any Keys that the call has will be combined with any Keys that the called Collaboration might have, creating a larger set for that level. Section 9.4.4 needs to be updated Issue 324 deals with how a given level deals with multiple Keys--They are alternative. Any one of the Keys can be initialized and used. If another Key is to be used for the same instance, then it must be initialized in conjunction with an already initialized key (to tie it to the proper instance). Reassign this issue to Conrad |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 02:50 PM ] |
|
-----------Proposal----------------Apr 6, 2010---------------------------
##Proposed Resolution: Fixed Called collaborations can have messages that don't have the correlation keys of the caller. The internal structure of messages is not specified in BPMN, but correlation keys applying to message flow establish property requirements on the contents of the message. The correlation keys applying to a message flow are all the keys of the containers of the message flow, including containers transitively through calls of collaborations or choreographies. Above Figure 8.18 (The Correlation Class Diagram) insert a new paragraph: Correlation can be applied to message flows in Collaboration and Choreography, as described in Chapters XXXCollaboration and XXXChoreography. The keys applying to a message flow are the keys of containers or groupings of the message flow, such as Collaborations, Choreographies, and Conversation Nodes, and Choreography Activities. This might result in multiple correlation keys applying to the same message flow, perhaps due to multiple layers of containment. In particular, calls of Collaborations and Choreographies are special kinds of Conversation Nodes and Choreography Activities, respectively, and are considered a kind of containment for the purposes of correlation. The correlation keys specified in the caller apply to message flow in a called collaboration or choreography. |
[BPMNFTF-329] [OMG 14832] Confusion about Performers and other roles that Resources play for Activities
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Meera Srinivasan (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
******************************************************************************* Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 10 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 131 Title: Confusion about Performers and other roles that Resources play for Activities Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Should Performers be reusable--at least within a Process? How do tools add additional types of Resource/Activity Roles (e.g., overseer, manager, etc.)? Are the current extension mechanisms sufficient? Should Performer be a sub-class of ActivityResource or referenced by it? ##Proposed Resolution: Close, No Change The ActivityResource/Performer are not reusable, the Resource element referenced by them is. This schema allows most of reuse use cases. So the FTF conclusion is to close with no change, since there is no change needed. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:12 PM ] |
|
As per March F2F Meeting:
- Keep the issue. Merge it with - We need to assign it to someone |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 06:59 AM ] |
|
proposalScheduledForBallot10
Meera is helping with these issues |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 01:07 PM ] |
|
Following places need to be updated to reflect this:
(1) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 131 Currently the Performer is a sub-class of Activity Resource. The Activity has a 1-many relationship with ActivityResource and supports linking multiple Performers to an Activity. It is quite common to have a Performer responsible for more than one Activity in the Process. Therefore, provision must be made to link multiple Activities to a Performer. There should be a many-many relationship between the Activity and the Performer. |
| Comment by Mariano Benitez (Oracle) [ 30/Mar/10 01:28 PM ] |
|
maybe my understanding is wrong, but isn't the Resource element inside the ActivityResource (ResourceRole) the reusable element?
- I believe we are covering most of the normal uses, leaving out the use case where someone would really need to reuse the Performer/Owner/ResourceRole definition across multiple activities, but I could live without supporting this case for now. The option of making ActivityResource/ResourceRole reusable requires: - Make ResourceRole a top-level element - Activity and Process should allow both references and definitions in the same way as Event Definitions. So my proposal is to close with now change, since the current metamodel can cover most of use cases. |
| Comment by Suzette Samoojh (IBM) [ 30/Mar/10 02:59 PM ] |
|
I agree with Mariano's comments.
I'll just add that if reuse of the ActivityResource/ResourceRole is needed, there's always the option of Global Tasks. |
[BPMNFTF-328] [OMG 14831] A New Hook for Organizational Models?
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
******************************************************************************* Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 10 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 131 Title: A New Hook for Organizational Models? Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing. The Resource class could be renamed to make it more generic, or a new class for Organization could be added. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:30 PM ] |
|
As per March F2F Meeting:
- Agreed to keep the issue but to lower the priority. - The issue need to be assiged to someone |
| Comment by Stephen White [ 18/Mar/10 08:16 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 05/Apr/10 12:05 AM ] |
| Update the proposed issue resolution to say that this is a request for an enhancement, but those not represent an implementation issues. So the FTF agreed to defer it and leave this issue in the wish list for the RTF. |
| Comment by Ivana Trickovic [ 06/Apr/10 03:20 PM ] |
|
##Proposed Resolution: Defer
This is a request for a new element. The FTF agreed to defer this issue to a future RTF. |
[BPMNFTF-325] [OMG 14826] Event marker quality is poor
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
list-of-disfigured-graphical-elements.docx
|
| Description |
|
##Source: IBM (Suzette Samoojh ssamoojh@ca.ibm.com)
******************************************************************************* Name: Suzette Samoojh Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: All FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 01/14/2009 Page: All Title: Event marker quality is poor Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The markers that appear in the Beta spec are of really poor quality (they look almost hand-drawn). They have a negative impact on the overall quality of the spec. See table 10.86 for examples, but really is prevalent in a lot of the markers throughout the document. Note that the same markers in prior versions (e.g. the v0.9.14) were of much greater quality. Somehow the marker quality degraded, probably an accidental side-effect of some sort of document conversion. ##Proposed Resolution: Fixed ALL images were updated with replacements of adequate resolution, we are not including specific diagrams because most of the were updated based on the resolutions of other issues. |
| Comments |
| Comment by Stephen White [ 03/Dec/09 04:26 PM ] |
| This was due to the conversion of Word documents into FrameMaker documents. The figures will be replaced. |
| Comment by Falko Menge [ 29/Apr/10 09:14 AM ] |
| During our example validation work we created a list of affected figures. (See attachment: list-of-disfigured-graphical-elements.docx) |
| Comment by Mariano Benitez (Oracle) [ 11/May/10 12:14 PM ] |
|
Spec-Draft3-review
Draft3 the following tables/figures should be updated, at least Table 10.86 - Event Sub-Process Start Event Types Figure 10.71 - End Event Table 10.88 - End Event Types Figure 10.72 - Intermediate Event Table 10.89 - Intermediate Event Types in Normal Flow Table 10.90 - Intermediate Event Types Attached to an Activity Boundary Table 10.93 - Types of Events and their Markers Figure 10.74 - Cancel Events Figure 10.75 - Compensation Events Figure 10.79 - Error Events Figure 10.81 - Escalation Events Figure 10.83 - Link Events Figure 10.84 - Link Events Used as Off-Page Connector Figure 10.85 - A Process with a long Sequence Flow Figure 10.86 - A Process with Link Intermediate Events used as Go To Objects Figure 10.87 - Link Events Used for looping Figure 10.88 - Message Events Figure 10.91 - None Events |
| Comment by Ivana Trickovic [ 17/May/10 03:23 PM ] |
|
As per the meeting of May 17th: Steve to make updates
|
| Comment by Stephen White [ 19/May/10 09:34 PM ] |
| Done |
[BPMNFTF-324] [OMG 14648] Multiple properties / keys clarification
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Karsten Ploesser (SAP) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
Does the first message in an Conversation need to have values for all the properties of a correlation key, or can some values appear in later messages? When a conversation has multiple correlation keys, do all the properties of all the keys need to match in each message, or just the properties for one of the keys? Can a message later in a conversation send values for only some of the properties in a key? ##Proposed Resolution: Fixed under Section 8.3.3, replace the text of the first bullet with this text: In plain, key-based correlation, Messages that are exchanged within a Conversation are logically correlated by means of one or more common CorrelationKeys. That is, any Message that is sent or received within this Conversation needs to carry the value of at least one of these CorrelationKey instances within its payload. A CorrelationKey basically defines a (composite) key. The first Message that is initially sent or received initializes one or more CorrelationKey instances associated with the Conversation, i.e., assigns values to its CorrelationProperty instances which are the fields (partial keys) of the Correlation-Key. A CorrelationKey is only considered valid for use, if the Message has resulted in all CorrelationProperty fields within the key being populated with a value. If a follow-up Message derives a CorrelationKey instance, where that CorrelationKey had previously been initialized within the Conversation, then the CorrelationKey value in the Message and Conversation MUST match. If the follow-up Message derives a CorrelationKey instance associated with the Conversation, that had not previously been initialized, then the CorrelationKey value will become associated with the Conversation. As a Conversation may comprise different Messages that may be differently structured, each CorrelationProperty comes with as many extraction rules (CorrelationPropertyRetrievalExpression) for the respective partial key as there are different Messages. under section 8.3.3 Correlation, the under the title "Key-based Correlation", replace the second paragraph with this text: At runtime the first Send Task or Receive Task in a Conversation MUST populate atleast one of the CorrelationKey instances by extracting the values of the CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, the populated CorrelationKey instances are used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the associated Conversation. Where these non-initiating Messages derive values for CorrelationKeys, associated with the Conversation but not yet populated, then the derived value will be associated with the Conversation instance. |
| Comments |
| Comment by Conrad Bock (NIST) [ 04/Aug/09 02:15 PM ] |
|
Conrad,
I doubt the spec is precise enough on that yet - so here is my personal take on what we want it to say: * All properties constituting a correlation key MUST (SHOULD?) be set by a single message in a conversation (Rationale: We don't want a partially set key.) * Not all correlation keys of a given conversation need to be set at any given time. (Rationale: Conversation keys could be added over the lifetime of a conversation, no reason to prevent this.) * When associating an (inbound) message with a conversation, all properties of all correlation keys contained in that message must match those already set for the conversation (instance). (Rationale: We could relax that, having it strict simplifies the rules and increases usability; I don't see why a message would ever contain multiple correlation keys some of which do *not* match, but could be convinced otherwise through scenarios. Of course a message does not have to contain properties for all correlation keys that may be used for a conversation, but those that it uses must match.) With that the answers to your questions would be: * Not all must be contained, some could be delivered later - for those correlation happens based on the keys that *were* already set by the first message. * Yes, all must match - see rationale above, we could relax that if we see a good reason. Hopefully that makes sense - and hopefully I got the terminology right, admittedly I didn't check back with the spec but answered from memory. Viele Grüße/Kind regards, -Matthias |
| Comment by Conrad Bock (NIST) [ 05/Aug/09 08:40 AM ] |
|
These clarification affects the second paragraph of the Key-based
Correlation subsection of Section 8.3.3 (Correlation): At runtime the first Send Task or Receive Task in a Conversation populates the CorrelationKey instance by extracting the values of the CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, this CorrelationKey instance is used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the associated Conversation. New keys might appear during the converstion. For example, the initial message from a customer placing an order might not include the order number. This is assigned by a new process instance and used to correlate messages later in the conversation. |
| Comment by Stephen White [ 30/Nov/09 07:22 PM ] |
| This issue is assigned to the Interaction Sub-Group, but the Process Orchestration Sub-Group might need to be involved. |
| Comment by Stephen White [ 07/Jan/10 06:33 PM ] |
|
---------------- Discussion during Conference Call on 2010-01-07 ----------------------
Example, start with Order ID Supplier generates a new ID. Each participant has it's own key Once you establish the link between a parent and child key, then you only need the key. How to "set" these keys. BPEL defines correlation sets. can be initialized. How does it get initialized in BPMN? Process data must relate to the key through the definitional Collaboration Property names don't necessarily have to be the same. There are expressions to map the name. We need to review the examples and maybe get more (e.g., a Sub-Conversation) the retrievalExpression gets the correct properties from the Message. Look at the example from the RFP work. Post a link on wiki To answer the questions of the issue: 1. Yes, values for all properties of a correlationKey must be provided in the first Message 2. The message must have all the properties of one of the defined keys for a Conversation (not necessarily for all of the keys) 3. No. all the properties of at least one key must be used for each Message. We need to answer these questions in the spec. and other questions. Other questions we had: How does a CorrelationKey get Initialized (especially after the Conversation has already started)? The first message with that key? Or do we need to do something? Does Conversation instance mean anything? We careful in the spec about that term. How do relate the property names of the Process to the property names of the Message? We see only a retrieval of the Message properties, but no direct connection to the Process properties. |
| Comment by Stephen White [ 13/Jan/10 05:51 PM ] |
|
----------------- Conference Call Discussion on 2010-01-13 -----------------------------
multiple correlation keys The keys represent alternatives Converstion instance doesn't mean anything. review this in spec Action: generate new issue Action: Assign to Karsten |
| Comment by Ivana Trickovic [ 10/Mar/10 11:19 PM ] |
|
As per March F2F Meeting:
Get proposal for |
| Comment by Stephen White [ 18/Mar/10 04:11 PM ] |
| proposalScheduledForBallot11 |
| Comment by Gary Brown [ 26/Mar/10 05:27 AM ] |
|
Proposed resolution:
Section 8.3.3 first bullet In plain, key-based correlation, Messages that are exchanged within a Conversation are logically correlated by means of one or more common CorrelationKeys. That is, any Message that is sent or received within this Conversation needs to carry the value of atleast one of these CorrelationKey instances within its payload. A CorrelationKey basically defines a (composite) key. The first Message that is initially sent or received initializes one or more CorrelationKey instances associated with the Conversation, i.e., assigns values to its CorrelationProperty instances which are the fields (partial keys) of the Correlation-Key. A CorrelationKey is only considered valid for use, if the Message has resulted in all CorrelationProperty fields within the key being populated with a value. If a follow-up Message derives a CorrelationKey instance, where that CorrelationKey had previously been initialized within the Conversation, then the CorrelationKey value in the Message and Conversation MUST match. If the follow-up Message derives a CorrelationKey instance associated with the Conversation, that had not previously been initialized, then the CorrelationKey value will become associated with the Conversation. As a Conversation may comprise different Messages that may be differently structured, each CorrelationProperty comes with as many extraction rules (CorrelationPropertyRetrievalExpression) for the respective partial key as there are different Messages. p67 Key-based Correlation - second para At runtime the first Send Task or Receive Task in a Conversation MUST populate atleast one of the CorrelationKey instances by extracting the values of the CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, the populated CorrelationKey instances are used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the associated Conversation. Where these non-initiating Messages derive values for CorrelationKeys, associated with the Conversation but not yet populated, then the derived value will be associated with the Conversation instance. |
| Comment by Gary Brown [ 26/Mar/10 05:28 AM ] |
|
New Proposed Resolution
|
[BPMNFTF-323] [OMG 14647] Section 10.2.3
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Rouven Day (SAP) | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: SAP (Rouven Day rouven.day@sap.com)
Section(s) of Spec: 10.2.3 Type: Editorial Description of issue: Section 10.2.3 says "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort." The second part of this sentence is not correct. It could not be that every User Task has to be scheduled through a task list manager. E.g. there are User Tasks where the user has to go to a system, open a transaction and enters some data. On complete and event is fired that tells the process engine that the task is completed. I consider this kind of task as a User Task as well, even though it is not scheduled through a task list manager. Proposal: Can we relax or remove the second part of the sentence? ##Proposed Resolution: Fixed Beta 1, August 2009 (pdf version) In section 10.2.3, sub-section "User Task" make the following changes. Include "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application. The lifecycle of the task is managed by a software component (called task manager) and is typically executed in the context of a process." instead of "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort." |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 01/Dec/09 04:14 PM ] |
|
I agree with Rouven's point. But I think we need to be careful with the new wording, to prevent confusion with Manual Tasks.
To provide an illustrative example, consider a manual process for writing a book. The writer is interacting with software (MS Word, online dictionaries, etc). But he is performing Manual Tasks, not User Tasks. So, use of a software application as the only criterion isn't sufficient. In addition to "assistance of a software application", I think the other criterion is that the task occurs within a process that is being executed by a process engine. The engine is aware of the task or of the task outcome in some way. |
| Comment by Ivana Trickovic [ 18/Mar/10 10:34 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 26/Mar/10 07:17 AM ] |
|
------------------- Proposal ------------ 2010-03-26 -------------------------------------------------
##Proposed Resolution: Fixed In section 10.2.3, sub-section "User Task" make the following changes. Include "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application. The lifecycle of the task is managed by a software component (called task manager) and is typically executed in the context of a process." instead of "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort." ---------------------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 26/Mar/10 07:17 AM ] |
| New Proposed Resolution |
[BPMNFTF-322] [OMG 14824] Continue versus terminate in loop
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Henk de Man | Assigned To: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Henk de Man Company: Cordys mailFrom: hdman@cordys.com Notification: Yes Specification: BPMN Section: 14.4.6 FormalNumber: dtc/2009-08-14 Version: 2.0 (Beta 1) RevisionDate: 8/14/2009 Page: 407 Title: Continue versus terminate in loop Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Required: Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop). This relates to what is e.g. said on page 407: "For a "terminate" End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated." So, differentation is required between the two modes of getting out of the loop. |
| Comments |
| Comment by Stephen White [ 01/Dec/09 05:53 PM ] |
| There was a slight change to the description as indicated by Henk de Man |
| Comment by Stephen White [ 13/Jan/10 05:40 PM ] |
|
--------------------- Conference Call Discussion on 2010-01-13 ----------------------
We are not sure we fully understand the issue. Based on what we understand, the requested functionality could be done by placing an interrupting boundary event on the looping/multi-instance activity. This would interrupt all instances of that activity. If the activity was a Sub-Process, then a Signal Event within the Sub-Process could trigger the boundary event. |
| Comment by Stephen White [ 16/Feb/10 11:09 AM ] |
|
Comment for Henk de Man:
Using a signal event within the multi-instance activity and an interrupting boundary signal event to solve this break requirement sound like a work around. Disadvantages are: - Signals are functional artifacts which you should not misuse for a break - A signal suggests publish subscribe where here we only want to break out of the looping - Standard languages have always the concept of break and continue (standard keywords) in relation with loops - The relation from throw and catch signal is not directly visual (no connector in between) Why not make different icons for break and continue? |
| Comment by Ivana Trickovic [ 09/Mar/10 11:29 PM ] |
|
As per March F2F Meeting:
- Agreed to defer this issue. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 10:29 AM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
[BPMNFTF-321] [OMG 14823] Persistent versus transient event trigger
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Henk de Man | Assigned To: | Hagen Volzer |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
Name: Henk de Man
Company: Cordys mailFrom: hdman@cordys.com Notification: Yes Specification: BPMN Section: 10.4.4 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 226 Title: Persistent versus transient event trigger Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Define for intermediate messages (intermediate event trigger) if the message should be persisted in the process scope when the intermediate message is not yet active. (See also workflow patterns from van der Aalst; e.g. http://www.workflowpatterns.com/evaluations/standard/index.php and http://www.workflowpatterns.com/patterns/control/new/wcp24.php). It relates to e.g. the following on page 226 in the BPMN 2.0 Beta 1 specification: "If the Event is used to "catch" the Event Trigger, then the token will remain at the Event until the Trigger occurs (e.g., the Message is received)." Differentiation is required between whether one wants to persist (or "defer") the trigger, or whether one wants to "lose" the trigger when the process is not yet in state to react. |
| Comments |
| Comment by Stephen White [ 06/Jan/10 03:28 PM ] |
|
------------------- Conference Call discussion on 2010-01-06 -------------------------------------
This is a feature request (?) A message is lost without token there at the Event (?) The request is to keep messages around until process is ready in addition to current semantics There is a work around by connecting a SF from start (?) Who receives the message? engine, process, etc. Does spec says that message is thrown away? It was explicit in V1.x, but not in 2.0. Got lost somehow. We need to specify what happens (could be part of this issue) The messages could be put in queue to wait. There are use cases for ignoring messages e.g., alternative paths through a process, one path that waits and event gateway. garbage collection should not be part of the spec Should keep messages or not specify What if there are multiple copies of the same message? First or latest when token arrives? Are messages lost? or just not used? A timing issue. The first to arrive for Event GW. no priority mechanism. How to specify the difference between holding early messages and ignoring them? Add a flag to allow things that arrive early. Hagen will look into execution semantics The MM change is simple. Applies to Receive Task as well. Assign to Hagen |
| Comment by Hagen Volzer [ 15/Feb/10 03:35 AM ] |
|
What happens to arriving messages if no event in the process is yet ready to receive is not specified in the spec indeed. There is also no clarification in BPMN 1 nor BPEL. It appears to be a quite complex issue, because several cases could occur. (1) A process instance that could consume the message is created but has not yet reached a corresponding receive event, (2) A process instance that could consume the message is not yet created, (3) A process instance that could consume the message was terminated.
I would expect an execution engine to buffer such messages by default. However, it is clear there would be time and space bounds to such buffering in practice. If we try to specify the behavior of the engine exhaustively, we have to cover a lot of different exception situations. There are probably also use cases for not buffering such messages. I would think that in practice, there is desire to tune these things very specifically. I am not sure to what extent we want to standardize this point. |
| Comment by Ivana Trickovic [ 10/Mar/10 04:15 AM ] |
|
As per March F2F Meeting:
- Agreed that this is an issue for implementers but not for the standard (specification). This would mandate a specific implementation, but there are different ways how this could be done and there is no preferred way of doing this. - Close (out of scope) with no changes to the specification. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:13 PM ] |
|
##Proposed Resolution: Closed, Out Of Scope
This issue cannot be fixed in this FTF. |
[BPMNFTF-320] [OMG 14822] The description of operationRef is not accurate
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Yu, zhangyzy@cn.ibm.com)
Specification: Business Process Model and Notation (BPMN) Section: 10/10.2.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 2009-08-14 Page: 169 Title: The description of operationRef is not accurate Nature: Clarification Severity: Minor Description: in this page, for Send Task, in Table 10.9 Send Task model associations. the description of operationRef is: This attribute specifies the operation that is invoked by the Service Task. But this description is not accurate because Send task is not a Service Task. the better description may be: This attribute specifies the operation that the Send Task will inovke to. This issue also happens on the Receive Task's operationRef's description because for Receive Task, the operationRef should describe what operation the Receive task will listen on. -------------------------- Proposal on 2010-01-06 ---------------------------------- ##Proposed Resolution: Fixed (a) Table 10.9, page 169 (199 pdf), second row, second column: change "Service Task" to "Send Task" (b) Table 10.10, page 170 (200 pdf), third row, second column: change "operation that is invoked by the Receive Task" to "operation through which the Receive Task receives the message" ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 06/Jan/10 08:54 PM ] |
|
-------------------------- Proposal on 2010-01-06 ----------------------------------
(a) Table 10.9, page 169 (199 pdf), second row, second column: change "Service Task" to "Send Task" (b) Table 10.10, page 170 (200 pdf), third row, second column: change "operation that is invoked by the Receive Task" to "operation through which the Receive Task receives the message" ----------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-319] [OMG 14820] Data Inputs the target of multiple Data Associations
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh ssamoojh@ca.ibm.com)
Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 200 Title: Data Inputs the target of multiple Data Associations Nature: Clarification Severity: Significant Description: Can a single Data Input be the target of multiple Data Associations? The spec does not explicitly disallow this. What would be the outcome of executing this model - would the last data association defined always overwrite the results of executing prior ones? Is there a use-case or scenario where this produces meaning results, or should this pattern be disallowed? ##Proposed Resolution: Fixed Add the following paragraph after the last paragraph in Section 10.3.2 Execution Semantics for Data Once an InputSet becomes "available", all DataAssociations whose target is any of the DataInputs of the InputSet are executed. These executions fill the Activity DataInputs and the execution of the Activity can begin. When an Activity finishes execution, all DataAssociations whose sources are any of the DataOutputs of the OutputSet are executed. These executions copy the values from the DataOutputs back to the container's context (DataObjects, Properties, etc). *Execution Semantics for DataAssociation* The execution of any DataAssociation must follow these semantics: a) If the DataAssociation specifies a "transformation" Expression, this expression is evaluated and the result is copied to the targetRef. This operation replaces completely the previous value of the targetRef element. b) For each "assignment" element specified: *) Evaluate the Assignment's "from" expression and obtain the *source value* *) Evaluate the Assignment's "to" expression and obtain the *target element*. The *target element* can be any element in the context or a sub-element of it (e.g. a DataObject or a sub-element of it). *) Copy the *source value* to the *target element*. c) If no "transformation" Expression nor any "assignment" elements are defined in the DataAssociation: *) copy the DataAssociation "sourceRef" value into the "targetRef". Only one sourceRef element is allowed in this case. -- Add the following sentence in Section 14.2.2 Activity, at the end of the bullet that starts with "When some data InputSet becomes available," Please refer to section 10.3.2 for a description of the execution semantics for DataAssociations. " |
| Comments |
| Comment by Hagen Volzer [ 25/Nov/09 03:16 AM ] |
| I see two cases for a single Data Input being the target of multiple Data Associations. (1) The multiple data associations are triggered alternatively, e.g., by different tasks on alternative paths. That seems to be a valid use case. (2) They are triggered concurrently. I think that would be a modeling error in most of the cases and I would expect a tool to give me a warning at static analysis time. I would not rule it out though and the semantics should be that data association executed last overrides the previous value. |
| Comment by Suzette Samoojh (IBM) [ 26/Nov/09 05:47 PM ] |
|
Okay. Hagen's use case #1 makes sense.
From a semantics point of view, the described behavior (the last one executed overrides previous values) requires that we execute all data associations in an input set before determining if the input set has been satisfied. Without this, the input set may be considered satisfied by the value of the first data association. Reading what the spec says, it does seem to describe exactly this. Although I would appreciate another eyes reading that section to see if I'm reading too much between the lines (Beta spec, spec pg 393, pdf pg 423, second paragraph). So, assuming I'm reading right, I'm okay with closing this with no change. |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:38 PM ] |
|
One other thought ...
If two data associations target a single data inputs, and executing the first produces a value, but executing the second does not, I assume the value of the first is kept (we'd have to, to satisfy use-case 1). And so in this case a 'null' does not override prior values. So I withdraw my statement that I'm okay with closing this with no change. I think we do need some clarification to the execution semantics to ensure we get consistent behavior and interpretation. |
| Comment by Mariano Benitez (Oracle) [ 30/Nov/09 01:42 PM ] |
|
---------- Discussion during FTF call on 2009-11-30 ----------
Mariano Benitez will lead the issue with some help to write some explanatory text making explicit the expected behaviour when 2 or more Data Associations target the same Data Input. |
| Comment by Conrad Bock (NIST) [ 13/Jan/10 11:06 AM ] |
|
The issue applies to a DataInput targeted by a single DataAssociation
where multiple pieces of data arrive over time. For example, the source of the data association might be from activities in a loop that generate multiple pieces of data over time before the target activity has had a chance to execute. The spec doesn't say whether new data overwrites existing data or is queued. |
| Comment by Mariano Benitez (Oracle) [ 13/Jan/10 03:28 PM ] |
|
I am drafting a description of the execution semantics for the data association, not yet final
--- Add the following paragraph in section 10.3.2 Execution Semantics for Data DataAssociations contained in an Activity or Event are executed the following way: For each DA - if there is a transformation, -- execute it and copy the value to the target - for each assignment -- evaluate the from expression and obtain the FROM value -- evaluate the to expression and obtain the TO target -- copy the value - if no transformation and no assignments -- copy the source to the target |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:59 PM ] |
| proposalScheduledForBallot11 |
| Comment by Mariano Benitez (Oracle) [ 07/Apr/10 01:32 PM ] |
|
By writing the resolution for this issue, I understand that Assignments require a separate "operation" attribute that defines what to do with the target.
(append, copy, insert before, insert after, etc). This attribute should be a URI with some predefined values for normal operations, but it should be extensible. I will fill a separate issue with this. |
[BPMNFTF-318] [OMG 14819] Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
MM_DataAssociation.jpg
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 200 Title: Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement Nature: Revision Severity: Significant Description: See figure 10.61. The "sourceRef" assocation. The cardinality on the DataAssociation end is 1. This tells me that any given DataAwareElement must be the source of exactly one DataAssociation. This doesn't work: - DataAwareElement are not required to participate in data associations. - Data Objects can be the source of multiple data associations. So the cardinality should be 0..n --------PROPOSAL---------------------01/11/2010------------------------------------------ ##Proposed Resolution: Fixed Replace Figure 10.61. See here in particular, the corrected cardinality (circled in red): http://www.osoa.org/jira/secure/attachment/10583/10583_MM_DataAssociation.jpg --------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 05:05 PM ] |
|
--------PROPOSAL---------------------01/11/2010------------------------------------------
Replace Figure 10.61. See MM_DataAssociation.jpg, and in particular, the corrected cardinality (circled in red). |
| Comment by Mariano Benitez (Oracle) [ 12/Jan/10 05:48 AM ] |
|
New Proposed Resolution: Fixed
See comments above from Suzette |
[BPMNFTF-317] [OMG 14818] Unclear/contradictory handling of visualized Data nputs/Outputs
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-data_updatedFor317.doc
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 191, 193 Title: Unclear/contradictory handling of visualized Data Inputs/Outputs Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The spec does not provide much clarification on how the Data Inputs/Outputs notation is used. As an example, consider a process that is calling another process. The called process has Data Inputs and Data Outputs. If I create a data association from the calling process to the Call Activity, clearly the target of that data association would be a data input of the called process. And yet the spec states that: - DataInputs MUST NOT have incoming DataAssociations. So, there's a contradiction here. DataAssociations do and should target DataInputs. Or, is that statement intended to describe visualization of the DataAssociation (i.e. the DataAssociation visually stops at the CallActivity boundary and does not visually connect to the Data Input, even if it is actually connected in the semantic model)? If the latter, why not allow the Data Association to connect to the Data Inputs? Doing so would result in a more explicit visualization of the underlying semantics. If I had multiple Data Inputs, I would be able to tell at a glance which Data Input is being targetted by which Data Association. ##Proposed Resolution: Fixed 1. Pdf pg 221, section titled "Data Inputs". Replace entire second paragraph (including sub-bullets) with the following: [See word doc for formatted version: http://www.osoa.org/jira/secure/attachment/10674/10_process-data_updatedFor317.doc] The Data Input is an item-aware element. Data Inputs may be visualized in a Process diagram to show the inputs to the top-level Process or to show the inputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process). - Visualized DataInputs have the same notation as DataObjects, except MUST contain a small, unfilled block arrow (see Figure 10.55). - DataInputs MAY have incoming DataAssociations. - If the Data Input is directly contained by the top-level Process, it MUST NOT be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events may be the target of Data Associations in the model. - If the Process is being called from a Call Activity, the Data Associations that target the data inputs of the Call Activity in the underlying model may be visualized such that they connect to the corresponding data inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations target the data inputs of the Call Activity and not the data inputs of the called Process. 2. Pdf pg 223, section titled "Data Outputs". Replace entire second paragraph (including sub-bullets) with the following: [See word doc for formatted version: http://www.osoa.org/jira/secure/attachment/10674/10_process-data_updatedFor317.doc] The DataOutput is an item-aware element. DataOutput elements may be visualized in a Process diagram to show the outputs of the top-level Process, or to show the outputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).. - Visualized DataOutputs have the same notation as DataObjects, except MUST contain a small, filled block arrow (see Figure 10.57). - DataOutputs MAY have outgoing DataAssociations. - If the Data Output is directly contained by the top-level Process, it MUST NOT be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events may be the source of Data Associations in the model. - If the Process is being called from a Call Activity, the Data Associations that originate from the data outputs of the Call Activity in the underlying model may be visualized such that they connect from the corresponding data outputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations originate from the data outputs of the Call Activity and not the data outputs of the called Process |
| Comments |
| Comment by Stephen White [ 06/Jan/10 08:12 PM ] |
|
------------------- Conference Call discussion on 2010-01-06 -------------------------------------
There are use cases of DataInputs can have incoming Data Associations Should data associations cross process boundaries? For embedded yes, For called processes? Only a visualization? What are the Call Activity inputs? As matched up with the input of the called process? The visualization could be different from the model construction. The spec says that Call Activities must not define their own inputs and outputs. A clarification needed, new issue. They must exactly match. The spec says use the inputs of the called process Double check with Mariano. Action: create new issue. Suzette Resolution for this issue is the remove the statement. Clarify the visualization. Separate clarification for embedded and called will need more work. Related to issue about fixing figure 7.8 Related to the new issue Action: Assign to Steve |
| Comment by Ivana Trickovic [ 10/Mar/10 11:24 PM ] |
|
As per March F2F Meeting:
- Need to correct the statement. Say that DataInputs MAY have incoming DataAssociations (it is semantic statement). - Data inputs of any activity can be target of Data Association (this is a semantic statement). - In case of (expanded) call activity the data association can visually cross the boundary to connect the Data Input of the called processes. The similar applies for Data Output. |
| Comment by Suzette Samoojh (IBM) [ 22/Mar/10 07:28 PM ] |
| proposalScheduledForBallot11 |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 04:46 PM ] |
|
---------------------------------------------------------------------------
Proposed Resolution: Fixed 1. Pdf pg 221, section titled "Data Inputs". Replace entire second paragraph (including sub-bullets) with the following: [See attached word doc for formatted version: http://www.osoa.org/jira/secure/attachment/10674/10_process-data_updatedFor317.doc] The Data Input is an item-aware element. Data Inputs may be visualized in a Process diagram to show the inputs to the top-level Process or to show the inputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process). - Visualized DataInputs have the same notation as DataObjects, except MUST contain a small, unfilled block arrow (see Figure 10.55). - DataInputs MAY have incoming DataAssociations. - If the Data Input is directly contained by the top-level Process, it MUST NOT be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events may be the target of Data Associations in the model. - If the Process is being called from a Call Activity, the Data Associations that target the data inputs of the Call Activity in the underlying model may be visualized such that they connect to the corresponding data inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations target the data inputs of the Call Activity and not the data inputs of the called Process. 2. Pdf pg 223, section titled "Data Outputs". Replace entire second paragraph (including sub-bullets) with the following: [See attached word doc for formatted version: http://www.osoa.org/jira/secure/attachment/10674/10_process-data_updatedFor317.doc] The DataOutput is an item-aware element. DataOutput elements may be visualized in a Process diagram to show the outputs of the top-level Process, or to show the outputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).. - Visualized DataOutputs have the same notation as DataObjects, except MUST contain a small, filled block arrow (see Figure 10.57). - DataOutputs MAY have outgoing DataAssociations. - If the Data Output is directly contained by the top-level Process, it MUST NOT be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events may be the source of Data Associations in the model. - If the Process is being called from a Call Activity, the Data Associations that originate from the data outputs of the Call Activity in the underlying model may be visualized such that they connect from the corresponding data outputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations originate from the data outputs of the Call Activity and not the data outputs of the called Process |
| Comment by Reiner Hille-Doering [ 09/Apr/10 10:55 AM ] |
|
Szuette,
in the meeting in Walldorf we mentioned another case where a DataInput of a Process can have an incoming DataAssociation: Assume you want to use the same process both, for being called from outside and inside of a CallActivity. In such case the process receives its input in two different manners: 1. For extenal call, the data is received as output of a Message Start Event. 2. In the CallActivity it is available as DataInput. To solve this, we agreed that there should be the possibility to have a DataAssociation from the StartEvent (more specificly the StartEvent's DataOutput) to the Process's DataInput. Do you think this should be added to your section pg. 221? Or is this handled in another Jira? Reiner. |
| Comment by Suzette Samoojh (IBM) [ 19/Apr/10 05:24 PM ] |
|
Reiner,
That's being covered by Mariano, through another JIRA issue (I don't recall the number at the moment). |
| Comment by Reiner Hille-Doering [ 21/Apr/10 08:18 AM ] |
| Yes, found it: 470 and 359. |
[BPMNFTF-316] [OMG 14817] Data Inputs/Outputs on Subprocesses
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Reiner Hille-Doering |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-activities_316.doc
10_process-activities_316.doc
10_process-data_316.doc
BPMNFTF-316-Semantic.xsd.diff
datahandling-embedded-MI-subprocess.xml
datahandling-MI-servicetask.xml
|
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.3 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 191, 193 Title: Data Inputs/Outputs on Subprocesses Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: The spec isn't clear on the relationship between visual Data Inputs/Outputs and embedded subprocesses. Pg 191 states that "DataInput elements may appear in a Process diagram to show the inputs the Process as a whole ...". There's a similar statement on pg. 193 for Data Outputs. The phrase "the Process as a whole" almost reads like visualized Data Inputs/Outputs are only applicable to Processes (and not to embedded subprocesses). ##Proposed Resolution: Fixed Modify/include the following text to chapter 10.3 - "Data Input and Output", directly before Figure 10.8 (see Attachment http://www.osoa.org/jira/secure/attachment/10707/10_process-data_316.doc): Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via Multi Instance Loop Characteristics. Modify/include the following text to chapter 10.2.8 - "Multi-Instance Characteristics" (see Attachment http://www.osoa.org/jira/secure/attachment/10708/10_process-activities_316.doc): Table 10.3 - MultiInstanceLoopCharacteristics attributes and model associations loopDataInputRef: ItemAwareElement [0..1] This ItemAwareElement is used to determine the number of Activity instances, one Activity instance per item in the collection of data stored in that ItemAwareElement element. For Tasks it is a reference to a DataInput which is part of the Activity's InputOutputSpecification. For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process. In order to initialize a valid multi-instance, either the loopCardinality Expression or the loopDataInput MUST be specified. loopDataOutputRef: ItemAwareElement [0..1] This ItemAwareElement specifies the collection of data, which will be produced by the multi-instance. For Tasks it is a reference to a DataOutput which is part of the Activity's InputOutputSpecification. For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process. inputDataItem: DataInput [0..1] A DataInput, representing for every Activity instance the single item of the collection stored in the loopDataInput. This DataInput can be the source of DataInputAssociation to a data input of the Activity's InputOutputSpecification. The type of this DataInput MUST the scalar of the type defined for the loopDataInput. outputDataItem: DataOutput [0..1] A DataOutput, representing for every Activity instance the single item of the collection stored in the loopDataOutput. This DataOutput can be the target of DataOutputAssociation to a data output of the Activity's InputOutputSpecification. The type of this DataOutput MUST the scalar of the type defined for the loopDataOutput. Table 10.37 - MultiInstanceLoopCharacteristics XML schema (change loopDataInput to loopDataInputRef with new type QName; change loopDataOutput to loopDataOutputRef with new type QName; change of inputDataItem to type tDataInput; change of outputDataItem to type tDataOutput) <xsd:complexType name="tMultiInstanceLoopCharacteristics"> <xsd:complexContent> <xsd:extension base="tLoopCharacteristics"> <xsd:sequence> <xsd:element name="loopCardinality" type="tExpression" minOccurs="0" maxOccurs="1"/> <xsd:element name="loopDataInputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/> <xsd:element name="loopDataOutputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/> <xsd:element name="inputDataItem" type="tDataInput" minOccurs="0" maxOccurs="1"/> <xsd:element name="outputDataItem" type="tDataOutput" minOccurs="0" maxOccurs="1"/> <xsd:element ref="complexBehaviorDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="completionCondition" type="tExpression" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="isSequential" type="xsd:boolean" default="false"/> <xsd:attribute name="behavior" type="tMultiInstanceFlowCondition" default="all"/> <xsd:attribute name="oneBehaviorEventRef" type="xsd:QName" use="optional"/> <xsd:attribute name="noneBehaviorEventRef" type="xsd:QName" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> Note: The attached diff from Tammo is not complete, so better use the schema above. |
| Comments |
| Comment by Stephen White [ 06/Jan/10 08:02 PM ] |
|
------------------- Conference Call discussion on 2010-01-06 -------------------------------------
DataInputs and Outputs can also be used for embedded sub-processes. This should be made more clear. The statement "process as whole" by itself is confusing. A simple addition to that sentence in the spec would resolve the issue. The part of the sentence that says "which are passed along as the inputs of Activities by DataAssociations" can be removed. Action: assign to Steve for a proposal. |
| Comment by Ivana Trickovic [ 10/Mar/10 08:32 AM ] |
|
As per March F2F Meeting:
- Agreed to preclude DataInputs and Outputs for embedded sub-processes. - DataInputs and Outputs MUST not be used for embedded sub-processes (including ad-hoc processes). |
| Comment by Conrad Bock (NIST) [ 10/Mar/10 09:26 AM ] |
|
I think users would find it helpful to use Data Inputs and Outputs on
subprocesses, even though the subprocess isn't reused. Data I/O might the "access" points for the outer diagram for some users. In general, it's simpler for the user (and probably implementations also) if the capabilities of reusable processes and subprocess are the same. |
| Comment by Ivana Trickovic [ 10/Mar/10 11:41 AM ] |
|
Updated meeting minutes (March F2F Meeting):
Agreed to preclude DataInputs and Outputs for embedded sub-processes. DataInputs and Outputs MUST not be used for embedded sub-processes (including ad-hoc processes). This is not visual change but the structural change. Do not change the MM but add this sentence in the specification text. This proposal is not valid for multi-instance activities. Reconsider the multi-instance activity. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 07:42 AM ] |
|
Clarification for MI activities:.
- The multi-instance loop characteristics (MILC) is changed such the type of inputDataItem becomes DataInput (instead of Property), and outputDataItem becomes DataOutput (instead of Property). - For Tasks, that DataInput is the input of the "inner" task, e.g., in the case of a service task, used as the input for the invoked operation, and that DataOutput is the output from the "inner" task. The MILC also references the input collection via the loopDataInput reference, and the output collection via the loopDataOutput references -- those collections are inputs and outputs of the MI task. - For embedded multi-instance subprocesses, this results in having a data input and a data output, as part of the MILC mix-in ... non-MI embedded subprocesses continue to not have data inputs/outputs. For embedded multi-instance subprocesses, the loopDataInput and loopDataOutput references refer to set-valued DataObjects in the context of that subprocess. |
| Comment by Matthias Kloppmann (IBM) [ 11/Mar/10 07:43 AM ] |
| Assigned Reiner -- Tammo will help by providing an example and more. |
| Comment by Tammo van Lessen [ 11/Mar/10 08:47 AM ] |
| As per Matthias proposal, the attachments reflect the schema change and two example instances for the data handling in embedded MI sub-processes and MI tasks. |
| Comment by Tammo van Lessen [ 11/Mar/10 09:52 AM ] |
| the XSD diff is made against the beta1 xsd. |
| Comment by Reiner Hille-Doering [ 22/Mar/10 07:30 AM ] |
|
proposalScheduledForBallot11
|
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 05:05 PM ] |
|
Reiner,
Please also see |
| Comment by Reiner Hille-Doering [ 12/Apr/10 07:30 AM ] |
|
##Proposed Resolution: Fixed
Modify/include the following text to chapter 10.3 - "Data Input and Output", directly before Figure 10.8 (see Attachment 10_process-data_316.doc): Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via Multi Instance Loop Characteristics. Modify/include the following text to chapter 10.2.8 - "Multi-Instance Characteristics" (see Attachment 10_process-activities_316.doc): Table 10.3 - MultiInstanceLoopCharacteristics attributes and model associations loopDataInputRef: ItemAwareElement [0..1] This ItemAwareElement is used to determine the number of Activity instances, one Activity instance per item in the collection of data stored in that ItemAwareElement element. For Tasks it is a reference to a DataInput which is part of the Activity's InputOutputSpecification. For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process. In order to initialize a valid multi-instance, either the loopCardinality Expression or the loopDataInput MUST be specified. loopDataOutputRef: ItemAwareElement [0..1] This ItemAwareElement specifies the collection of data, which will be produced by the multi-instance. For Tasks it is a reference to a DataOutput which is part of the Activity's InputOutputSpecification. For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process. inputDataItem: DataInput [0..1] A DataInput, representing for every Activity instance the single item of the collection stored in the loopDataInput. This DataInput can be the source of DataInputAssociation to a data input of the Activity's InputOutputSpecification. The type of this DataInput MUST the scalar of the type defined for the loopDataInput. outputDataItem: DataOutput [0..1] A DataOutput, representing for every Activity instance the single item of the collection stored in the loopDataOutput. This DataOutput can be the target of DataOutputAssociation to a data output of the Activity's InputOutputSpecification. The type of this DataOutput MUST the scalar of the type defined for the loopDataOutput. Table 10.37 - MultiInstanceLoopCharacteristics XML schema (change loopDataInput to loopDataInputRef with new type QName; change loopDataOutput to loopDataOutputRef with new type QName; change of inputDataItem to type tDataInput; change of outputDataItem to type tDataOutput) <xsd:complexType name="tMultiInstanceLoopCharacteristics"> <xsd:complexContent> <xsd:extension base="tLoopCharacteristics"> <xsd:sequence> <xsd:element name="loopCardinality" type="tExpression" minOccurs="0" maxOccurs="1"/> <xsd:element name="loopDataInputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/> <xsd:element name="loopDataOutputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/> <xsd:element name="inputDataItem" type="tDataInput" minOccurs="0" maxOccurs="1"/> <xsd:element name="outputDataItem" type="tDataOutput" minOccurs="0" maxOccurs="1"/> <xsd:element ref="complexBehaviorDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="completionCondition" type="tExpression" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="isSequential" type="xsd:boolean" default="false"/> <xsd:attribute name="behavior" type="tMultiInstanceFlowCondition" default="all"/> <xsd:attribute name="oneBehaviorEventRef" type="xsd:QName" use="optional"/> <xsd:attribute name="noneBehaviorEventRef" type="xsd:QName" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> Note: The attached diff from Tammo is not complete, so better use the schema above. |
| Comment by Reiner Hille-Doering [ 12/Apr/10 07:31 AM ] |
| Small corrections to older version |
| Comment by Reiner Hille-Doering [ 12/Apr/10 07:34 AM ] |
| The word attachment "2." is outdated. Please ignore. |
[BPMNFTF-315] [OMG 14816] Formalizing the Source-Target relationships between Link Intermediate Event
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Updated Link Event Metamodel.jpg
|
| Description |
|
##Source: IBM (Suzette Samoojh, ssamoojh@ca.ibm.com)
Specification: BPMN 2.0 Section: 10.4.4 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 236 Title: Formalizing the Source-Target relationships between Link Intermediate Event Nature: Enhancement Severity: Significant Description: Currently, there is no formalized way to relate Throw Link Events with their corresponding Catch Link Event(s). The spec briefly mentions that their names must be the same, but names are unreliable. - There is no constraint on names, so I could create multiple Catch Link Events with the same name, thus breaking the model. - Names are not used, in general throughout the spec, for formalizing relationships. Instead IDs are. - Users do sometimes assign different names to the Throw and Catch (for example "A" for the throw and "from A" for the catch). Recommendation: Add an explicit association from the Throw Link Event to the Catch Link Event. ---------------------- Proposed Resolution -------- 2010-01-11 --------------------- ##Proposed Resolution: Fixed Add a new bidirectional association to the LinkEventDefinition. http://www.osoa.org/jira/secure/attachment/10586/Updated+Link+Event+Metamodel.jpg If the LinkEventDefinition represents a 'throw' or 'source' link event, it will reference 1 LinkEventDefinitions representing the corresponding 'catch' or 'target' link event. If the LinkEventDefinition represents a 'catch' or 'target' link event, it will reference 1 or more LinkEventDefinitions representing the corresponding 'throw' or 'source' link events. Spec updates: (a) - Update Figure 10.70 to add new bidirectional association to the LinkEventDefinition class: http://www.osoa.org/jira/secure/attachment/10586/Updated+Link+Event+Metamodel.jpg - Add two new associations to Table 10.91: (b) sources: Used to reference the corresponding 'catch' or 'target' LinkEventDefinitions, when this LinkEventDefinition represents a 'throw' or 'source' LinkEventDefinition. (c) target: Used to reference the corresponding 'throw' or 'source' LinkEventDefinition, when this LinkEventDefinition represents a 'catch' or 'target' LinkEventDefinition. Corresponding additions will be made to the BPMN XSD. --------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 06/Jan/10 03:37 PM ] |
|
------------------- Conference Call discussion on 2010-01-06 -------------------------------------
We need a relationship between source and target Link Events in the model The name attribute is not good enough We should add a relationship from link event to itself, sources and target What about the execution semantics? More like a page connector? But the token movement analogy doesn't quite work with Catch Link Events. Action: Generate issue about link event execution semantics (throw and catch) -- Steve Action: Suzette will generate proposal for MM changes |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 05:00 PM ] |
|
----- PROPOSAL ------------------------01/11/2010 ------------------------------------------------------
Add a new bidirectional association to the LinkEventDefinition (see MM_LinkEventDefinition.jpg). If the LinkEventDefinition represents a 'throw' or 'source' link event, it will reference 0 or 1 LinkEventDefinitions representing the corresponding 'catch' or 'target' link event. If the LinkEventDefinition represents a 'catch' or 'target' link event, it will reference 0 or more LinkEventDefinitions representing the corresponding 'throw' or 'source' link events. Spec updates: - Update Figure 10.70 to add new bidirectional association to the LinkEventDefinition class (see attached MM_LinkEventDefinition.jpg). - Add two new associations to Table 10.91: sources: Used to reference the corresponding 'catch' or 'target' LinkEventDefinitions, when this LinkEventDefinition represents a 'throw' or 'source' LinkEventDefinition. target: Used to reference the corresponding 'throw' or 'source' LinkEventDefinition, when this LinkEventDefinition represents a 'catch' or 'target' LinkEventDefinition. Corresponding additions will be made to the BPMN XSD. |
| Comment by Mariano Benitez (Oracle) [ 12/Jan/10 05:47 AM ] |
|
New Proposed Resolution: Fixed
See previous comments from Suzette |
| Comment by Stephen White [ 12/Jan/10 06:35 PM ] |
| I think we should modify this (and perhaps some of the spec text) so that there MUST be a target Link Event. Otherwise, it would be like having half of a Sequence Flow. The token arriving at the Source would have no where to go. The execution semantics would not be defined. |
| Comment by Suzette Samoojh (IBM) [ 13/Jan/10 10:44 AM ] |
|
I agree that, for the model to be executable, every source should have a target. However, when someone is initially sketching out their process, they may add the source, and then later add the target (or vice versa). Until that point, I would say that the model is simply incomplete. That was my motivation for using 0 lowerBounds.
I don't know that we have a consistent design principle for incomplete models. I've sort of followed one particular style that we've applied (e.g. the association from ItemAwareElement to ItemDefinition is 0...1, even though the model is not actually executable without the ItemDefinition). But we certainly haven't followed that style everywhere (e.g. Interface requires an input Operation, even though in an incomplete model a user may choose to add the Operation later). I'm inclined to proceed with what was posted. But I don't really have a particularly strong opinion. |
| Comment by Stephen White [ 13/Jan/10 05:34 PM ] |
|
----------------------------- Conference Call Discussion on 2010-01-13 --------------------------
Fix relationship between link source and target Should there be a mandatory target incomplete models should allow multiplicity of zero to one validation for interchange or in good shape should not interchange without pairs Should we restrict users on this. How do we know which attributes and associations are truly optional vs incomplete? We allow optional in Section 16. For interchange purposes, lower bound of zero is ok even for elements with lower bound of one. Allows for incomplete models. So, we can be more restrictive in the MM to show the intent of the attributes for execution and validation. Action: Suzette will update the proposal to set the target multiplicity at 1. Action: we should review all 0..1 situations to make sure they reflect the intentions. generate an issue |
| Comment by Gary Brown [ 27/Jan/10 03:28 AM ] |
|
If there is now a formal link between the throw and catch events, should we also not define some additional semantics/validation rules to ensure that the throw is within the scope of the linked catch event?
I will raise this as a separate issue for consideration - as it is an enhancement to the proposal in this issue. |
| Comment by Suzette Samoojh (IBM) [ 27/Jan/10 10:06 AM ] |
|
Gary, I think it might already be stated. See the paragraph just above Figure 10.79 (pdf pg 274), which states that "The use of Link Events is limited to a single Process level (i.e., they cannot link a parent Process with a Sub-Process)."
I have no objections to adding a more formal and explicit statement (through another issue as suggested). But I could also live with what's already there. |
| Comment by Mariano Benitez (Oracle) [ 19/Apr/10 07:42 AM ] |
| updating image links so they are displayed in the final report. |
[BPMNFTF-314] [OMG 14815] Link Events - Constraints and Usage not clearly documented
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Suzette Samoojh (IBM) | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Suzette Samoojh Company: IBM Canada mailFrom: ssamoojh@ca.ibm.com Notification: No Specification: BPMN 2.0 Section: 10.4.4 FormalNumber: dtc/2009-08-14 Version: 2.0 RevisionDate: 08/14/2009 Page: 235-236 Title: Link Events - Constraints and Usage not clearly documented Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec. Very simply, it should express that: - A Catch Link Event should have no incoming Sequence Flow. - A Throw Link Event should have no outgoing Sequence Flow. Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above. Statements like: - If the Intermediate Event is used within normal flow: - Intermediate Events MUST be the target of a Sequence Flow. - An Intermediate Event MUST be a source for Sequence Flow. - An exception to this: a source Link Intermediate Event (as defined below), it is not required to have an outgoing Sequence Flow. - A Link Intermediate Event MUST NOT be both a target and a source of a Sequence Flow. - A Link Intermediate Event MAY be the target (target Link) or a source (source Link) of a Sequence Flow, but MUST NOT be both a target and a source. Recommendation: - Tighten up and simplify the constraint descriptions for Link Events. - Refrain from introducing new terms "source" and "target", or if the new terms are needed, clearly relate them to the existing "catch" and "throw" terms. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 10/Mar/10 03:45 AM ] |
| matching priorities with the issue. |
| Comment by Suzette Samoojh (IBM) [ 18/Mar/10 10:58 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 05/Apr/10 12:04 AM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 12:01 PM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-313] [OMG 14809] Allow Choreographies within a Conversation Diagram
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Notation, Schema, SoaML |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Steve White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 Beta Section: 11 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 293 Title: Allow Choreographies within a Conversation Diagram Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: Currently, Choreographies are not allowed between the Pools of a Conversation diagram. However, this capability would be very useful for some modeling problems, such as the linking of BPMN diagrams to SoaML. ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 24/Nov/09 04:51 PM ] |
| This issue will be handled if Issue 308 provides a merging of the Collaboration and Conversation diagrams. |
| Comment by Stephen White [ 19/Mar/10 03:08 PM ] |
| New Proposed Resolution |
[BPMNFTF-312] All Minor Editorial Issues that are not worth a separate issue
|
|
| Status: | New |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| File Attachments: |
BPMN20.ecore.html
BPMN20.exceptions
Complex Gateway in Choreography (Choreography) Proposal 2010-04-20 fixed.png
|
| Description |
|
The FTF can make small changes in the spec without creating an OMG issue and reporting on each one of them.
Please add comments in this issue for any minor editorial issue. The editors sub-team will include the fix in the spec and then add a comment indicating so. |
| Comments |
| Comment by Ivana Trickovic [ 23/Apr/10 02:26 PM ] |
|
Beta 1, Draft 1: Figure 8.18 - The Correlation Class Diagram
The CorrelationPropertyRetrievalExpression class shall contain FormalExpression. Use aggregation association (containment). Add MessageFlow class (and relevant associations) in the figure to make it understandable. |
| Comment by Mariano Benitez (Oracle) [ 26/Apr/10 12:19 PM ] |
|
Note on 2010-04-26:
The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be: - http://www.omg.org/spec/BPMN/20100524/MODEL for the semantic model XML Schema - http://www.omg.org/spec/BPMN/20100524/MODEL-XMI for the semantic model XMI - http://www.omg.org/spec/BPMN/20100524/DI for diagram interchange XML Schema - http://www.omg.org/spec/BPMN/20100524/DI-XMI for diagram interchange XMI xsds |
| Comment by Falko Menge [ 30/Apr/10 05:41 PM ] |
| For better comparison, the attachment 'Complex Gateway in Choreography (Choreography) Proposal 2010-04-20 fixed.png' contains a screenshot of the updated Choreography. |
| Comment by Falko Menge [ 30/Apr/10 05:44 PM ] |
|
Sorry, my last comment and the attachment 'Complex Gateway in Choreography (Choreography) Proposal 2010-04-20 fixed.png' were meant to go to |
| Comment by Falko Menge [ 30/Apr/10 06:11 PM ] |
|
In Figure 7.2 on page 16 (46), an example of a public process is shown. The process model at all seems to be fine, but the numeration of the message flows is unnecessary.
The numbers in the process model are not referenced in any other text or process diagram and that's why they might be confusing for the user. At worst, users could come to the conclusion that the numbers have a semantic meaning and are relevant for such diagrams. In BPMN these numbers do not have any importance for the interpretation of the process model in contrast to Communication Diagrams in UML where the numbers have a semantic meaning for the order of the sent messages. ----Proposal---------------- 04/13/2010 ------------------------- ##Proposed Resolution: Fixed (a) Figure 7.2 on page 16 (46): Remove the numeration in the labels of the message flows and remove the text 'Doctor'sOffice'. (b) Figure 8.14 on page 59 (89): Remove the numeration in the labels of the message flows. (c) Figure 10.5 on page 126 (156): Remove the numeration in the labels of the message flows and remove the text 'Doctor'sOffice'. |
| Comment by Falko Menge [ 30/Apr/10 06:22 PM ] |
|
Page 33 (66) Table 7.4 - Message Flow Connection Rules:
Increase the width of the fourth column so that the Task no longer overlaps the line of the table. |
| Comment by Falko Menge [ 03/May/10 12:04 PM ] |
|
As per FTF call on 2010-05-03, we decided to address the following comments as part of this issue:
http://www.osoa.org/jira/browse/BPMNFTF-548#action_16849 http://www.osoa.org/jira/browse/BPMNFTF-352#action_16851 |
| Comment by Reiner Hille-Doering [ 10/May/10 11:08 AM ] |
|
Inconsistencies between CMOF Metamodel and XSD (based on Ballot 10 without C-Merger). The report is generated from my little tool that merged CMOF and XSD. Full report and exception list (that I maintained in a simple EMF model) are in the attachments.
Inconsistencies in Global Elements 1. Did not find MOF Class GlobalConversation 2. Did not find MOF Class ImplicitThrowEvent 3. Did not find MOF Class Script 4. Did not find MOF Class Text Inconsistencies in attributes 1. No corresponding field found for TCollaboration.correlationKey on Collaboration 2. No corresponding field found for TConversationAssociation.innerMessageFlowRef on ConversationAssociation 3. No corresponding field found for TConversationAssociation.outerMessageFlowRef on ConversationAssociation 4. No corresponding field found for TConversationNode.messageFlowRef on ConversationNode 5. No corresponding field found for TConversationNode.conversationRef on ConversationNode 6. No corresponding field found for TConversationNode.correlationKeyRef on ConversationNode 7. No corresponding field found for TCorrelationSubscription.process on CorrelationSubscription 8. No corresponding field found for TCorrelationSubscription.process on CorrelationSubscription 9. No corresponding field found for TInputSet.optionalInputRefs on InputSet 10. No corresponding field found for TInputSet.whileExecutingInputRefs on InputSet 11. No corresponding field found for TOutputSet.optionalOutputRefs on OutputSet 12. No corresponding field found for TOutputSet.whileExecutingOutputRefs on OutputSet 13. No corresponding field found for TProcess.laneSet on Process 14. No corresponding field found for TSubProcess.laneSet on SubProcess Exceptions for attribute names Generally collection-typed attributes/references have are "plural" in MOF and "singular" in XSD. However, there are a number of different variants, where the plural "s" is placed. Normal cases, e.g.: Mof Attribute Name operations Xsd Attribute Name operation Mof Attribute Name errorRefs Xsd Attribute Name errorRef Strange cases: 1. GlobalTask (and others): resources - resourceRole 2. CallableElement: supportedInterfacesRefs - supportedInterfaceRef 3. InputSet: optionalInput - optionalInputRefs and whileExecutingInput - whileExecutingInputRefs 4. CallChoreographyActivity/CallConversation: calledElement - calledChoreographyRef 5. ConversationNode: participantsRef - participantRef 6. CorrelationPropertyRetrievalExpression: message - messageRef 7. ImplicitThowEvent vs. TImplicitThrowEvent (note the typo!) 8. Participant: endpointRefs - endPointRef (note different upper/lower case) 9. Resource: parameters - resourceParameter |
| Comment by Suzette Samoojh (IBM) [ 11/May/10 10:00 AM ] |
|
My analysis of the diffs in Reiner's report:
Inconsistencies in Global Elements > 1. Did not find MOF Class GlobalConversation I see the class in the current MM. Let's check the MOF again after Maged regenerates it. > 2. Did not find MOF Class ImplicitThrowEvent Typo in the MM. Is called "ImplicitTrowEvent" (missing 'h'). Fix via 312. > 3. Did not find MOF Class Script This is a valid difference. Is not needed in the UML (there's a String attribute in the ScriptTask class instead). > 4. Did not find MOF Class Text Same as above. Inconsistencies in attributes > 1. No corresponding field found for TCollaboration.correlationKey on Collaboration Is there in the current MM. > 2. No corresponding field found for TConversationAssociation.innerMessageFlowRef on ConversationAssociation > 3. No corresponding field found for TConversationAssociation.outerMessageFlowRef on ConversationAssociation The XSD is incorrect. The attributes in the XSD need to be renamed. Fix via 312. > 4. No corresponding field found for TConversationNode.messageFlowRef on ConversationNode Is there in the current MM. > 5. No corresponding field found for TConversationNode.conversationRef on ConversationNode No longer present in the current XSD. > 6. No corresponding field found for TConversationNode.correlationKeyRef on ConversationNode No longer present in the current XSD. > 7. No corresponding field found for TCorrelationSubscription.process on CorrelationSubscription > 8. No corresponding field found for TCorrelationSubscription.process on CorrelationSubscription No longer present in the current XSD. > 9. No corresponding field found for TInputSet.optionalInputRefs on InputSet > 10. No corresponding field found for TInputSet.whileExecutingInputRefs on InputSet > 11. No corresponding field found for TOutputSet.optionalOutputRefs on OutputSet > 12. No corresponding field found for TOutputSet.whileExecutingOutputRefs on OutputSet They are present in the MM, but incorrectly named. Fix via 312. > 13. No corresponding field found for TProcess.laneSet on Process > 14. No corresponding field found for TSubProcess.laneSet on SubProcess This is a valid difference. In the MM, they inherit this attribute from FlowElementsContainer. Exceptions for attribute names > 1. GlobalTask (and others): resources - resourceRole To make use of substitutionGroups, I need to call it "resourceRole" in the XSD. > 2. CallableElement: supportedInterfacesRefs - supportedInterfaceRef > 3. InputSet: optionalInput - optionalInputRefs and whileExecutingInput - whileExecutingInputRefs Fix via 312. > 4. CallChoreographyActivity/CallConversation: calledElement - calledChoreographyRef Please recheck with next version of the MM & XSD. I don't see a mismatch in the current files. > 5. ConversationNode: participantsRef - participantRef > 6. CorrelationPropertyRetrievalExpression: message - messageRef > 7. ImplicitThowEvent vs. TImplicitThrowEvent (note the typo!) > 8. Participant: endpointRefs - endPointRef (note different upper/lower case) > 9. Resource: parameters - resourceParameter Fix via 312. |
| Comment by Suzette Samoojh (IBM) [ 11/May/10 10:04 AM ] |
|
Summary: The following are valid inconsistencies to fix
> 2. No corresponding field found for TConversationAssociation.innerMessageFlowRef on ConversationAssociation > 3. No corresponding field found for TConversationAssociation.outerMessageFlowRef on ConversationAssociation > 9. No corresponding field found for TInputSet.optionalInputRefs on InputSet > 10. No corresponding field found for TInputSet.whileExecutingInputRefs on InputSet > 11. No corresponding field found for TOutputSet.optionalOutputRefs on OutputSet > 12. No corresponding field found for TOutputSet.whileExecutingOutputRefs on OutputSet > 2. CallableElement: supportedInterfacesRefs - supportedInterfaceRef > 3. InputSet: optionalInput - optionalInputRefs and whileExecutingInput - whileExecutingInputRefs > 5. ConversationNode: participantsRef - participantRef > 6. CorrelationPropertyRetrievalExpression: message - messageRef > 7. ImplicitThowEvent vs. TImplicitThrowEvent (note the typo!) > 8. Participant: endpointRefs - endPointRef (note different upper/lower case) > 9. Resource: parameters - resourceParameter The remaining items in the list are either a) valid differences (i.e. there's a reason for the difference), or b) they don't appear to occur anymore and will be rechecked when Reiner re-runs his report against the latest MOF and XSD. |
| Comment by Falko Menge [ 14/May/10 08:23 PM ] |
| The title of the PDF file should state the exact name and version of the specification. In Draft 3 it is still "Business Process Modeling Notation (BPMN), Version 1.0". |
| Comment by Ivana Trickovic [ 17/May/10 08:23 AM ] |
|
Beta 1, Draft 3:
Update section 6.3 Acknowledgements |
| Comment by Suzette Samoojh (IBM) [ 17/May/10 04:43 PM ] |
|
Beta 1, Draft 3: Typo in Table 8.68 (pdf pg 141) - Attribute "implementationRef" is missing the 't".
Spec change only, the XSD is correct. |
| Comment by Suzette Samoojh (IBM) [ 17/May/10 04:44 PM ] |
| Same typo in Table 8.67. |
| Comment by Ivana Trickovic [ 19/May/10 09:38 AM ] |
|
Updated the list of companies referred in section "Licenses".
The current list mentions OMG and companies that submitted BPMN 2.0 proposal in June 2009. Update this list to cover every company whose employees wrote text that ended up in the final specification (this would be minimum). |
| Comment by Falko Menge [ 07/Jun/10 07:33 AM ] |
|
spec-May24-review
The title of the PDF file of the convenience document as been changed as per http://www.osoa.org/jira/browse/BPMNFTF-312#action_16987 However, it now contains a typo. I propose to replace 'Modeli' with 'Model' in both convenience documents, i.e., dtc-2010-05-02 (BPMN 2.0 Specification with change-bars) and dtc-2010-05-03 (BPMN 2.0 Specification). |
| Comment by Falko Menge [ 07/Jun/10 08:44 AM ] |
|
spec-May24-review
http://www.osoa.org/jira/browse/BPMNFTF-312#action_16988 has been applied. However, there seems to be a grammatical issue in dtc-2010-05-02 (BPMN 2.0 Specification with change-bars) on page 19 (49 in PDF) where it states: '[...] the core teams that contributed to the content specification' Proposal: Add 'of this' in front of 'specification'. |
[BPMNFTF-311] [OMG 14646] Misleading copy/paste para regarding Properties
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-data - Issue 311.doc
|
| Description |
|
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.3.1 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 218 Title: Misleading copy/paste para regarding Properties Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: In the Lifecycle and Visibility section of Properties, the second para is misleading. The Para starts with "The visibility of a Property" this may lead to the misconception that Properties have depictions, which they don't. The para also refers to Process as flow elements and the scope example below does not really present the concept very well. ##Proposed Resolution: Fixed Beta 1, August 2009 (pdf version) (a) Page 183 Change: "A DataObject has a well-defined lifecycle, with resulting visibility constraints." to "A DataObject has a well-defined lifecycle, with resulting access constraints." (b) Page 184 Change: "Data Object elements are visible in a Process diagram." to "Data Object elements are visually displayed on a Process diagram." (c) Page 186 Change heading "Lifecycle and Visibility" to "Lifecycle and Accessability" Change: "The visibility of a Data Object is driven by its lifecycle. " to "The accessibility of a Data Object is driven by its lifecycle. " Change: "Data object 1" is visible to: "Process A," "Task A," "Sub-Process A," "Task B," "Sub-Process B," "Sub-Process C," "Task C," and "Task D." "Data object 2" is visible to: "Sub-Process A" and "Task B." "Data object 3" is visible to: "Sub-Process B," "Sub-Process C," "Task C," and "Task D." "Data object 4" is visible to: "Sub-Process C" and "Task C." to "Data object 1" can be accessed by: "Process A," "Task A," "Sub-Process A," "Task B," "Sub-Process B," "Sub-Process C," "Task C," and "Task D." "Data object 2" can be accessedby: "Sub-Process A" and "Task B." "Data object 3" can be accessed by: "Sub-Process B," "Sub-Process C," "Task C," and "Task D." "Data object 4" can be accessed by: "Sub-Process C" and "Task C." (d) Page 188 Change "Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visible within a Process diagram." to "Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visually displayed on a Process diagram." Change "Property elements are NOT visible in a Process diagram." to "Property elements are NOT visually displayed on a Process diagram." (e) Page 189 Change heading "Lifecycle and Visibility" to "Lifecycle and Accessability" Change "The visibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance present. As a result, a Property can only be accessed by its parent Flow Element or, when its parent Flow Element is a Process or Sub-Process, then by the immediate children of that Process or Sub-Process." to "The accessibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance present. As a result, a Property can be accessed by its parent Process, Sub-process or Flow Element. In case the parent is a Process or Sub-Process, then a property can be accesses by the immediate children (including children elements) of that Process or Sub-Process." (f) Page 190 Change The Properties of "Process A" are visible to: All elements (including children elements) of this Process The Properties of "Sub-Process A" are visible to: "Sub-Process A" and "Task B." The Properties of "Task C" are visible to: "Task C." to The Properties of "Process A" are accessible by: "Process A", "Task A", "Sub-Process A", "Task B", "Sub_Process B", "Sub-Process C", "Task C" and "Task D" The Properties of "Sub-Process A" are accessible by: "Sub-Process A" and "Task B." The Properties of "Task C" are accessible by: "Task C." (g) Page 191 Change "The DataInput is an item-aware element. DataInput elements may appear in a Process diagram to show the inputs to the Process as whole, which are passed along as the inputs of Activities by DataAssociations" to "The DataInput is an item-aware element. DataInput elements are visually displayed in on a Process diagram to show the inputs to the Process as whole, which are passed along as the inputs of Activities by DataAssociations." (h) Page 193 Change "The DataOutput is an item-aware element. DataOutput elements appear in a Process diagram to show the outputs of the Process as whole, which are passed along from the outputs of Activities by DataAssociations." to "The DataOutput is an item-aware element. DataOutput elements are visually displayed on a Process diagram to show the outputs of the Process as whole, which are passed along from the outputs of Activities by DataAssociations. " (i) Table 10.57 - DataAssociation model associations Change "Specifies an optional transformation expression. The actual scope of visible data for that expression is defined by the source and target of the specific data association types." to "Specifies an optional transformation expression. The actual scope of accessible data for that expression is defined by the source and target of the specific data association types." (j) Page 202 Change "The source of such a DataAssociation can be every item-aware element visible to the current scope, e.g., a Data Object, a Property or an Expression." to "The source of such a DataAssociation can be every item-aware element accessible in the current scope, e.g., a Data Object, a Property or an Expression." Change "The DataOutputAssociation can be used to associate a DataOutput contained within an ACTIVITY with any item-aware element visible to the scope the association will be executed in. The target of such a DataAssociation can be every item-aware element visible to the current scope, e.g, a Data Object, a Property or an Expression." to "The DataOutputAssociation can be used to associate a DataOutput contained within an ACTIVITY with any item-aware element accessible in the scope the association will be executed in. The target of such a DataAssociation can be every item-aware element accessible in the current scope, e.g, a Data Object, a Property or an Expression." (k) Page 203 Change "The visibility to the Expression language is defined based on the entities visibility to the Activity that contains the expression. All elements visible from the enclosing element of an XPath expression must be made available to the XPath processor." to "The accessibility by the Expression language is defined based on the entities accessibility by the Activity that contains the expression. All elements accessible from the enclosing element of an XPath expression must be made available to the XPath processor. " |
| Comments |
| Comment by Ivana Trickovic [ 10/Mar/10 08:35 AM ] |
|
As per March F2F Meeting:
- Probably editorial. -The following wording is misleading as Process is not a flow element. " ...when its parent Flow Element is a Process or Sub-Process, then by the immediate children of that Process or Sub-Process." Word "visibility" is misleading. Talk about accessibility of properties and data objects. - Revise the example. |
| Comment by Ivana Trickovic [ 18/Mar/10 10:34 AM ] |
| proposalScheduledForBallot10 |
| Comment by Ivana Trickovic [ 26/Mar/10 07:13 AM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 26/Mar/10 07:18 AM ] |
|
------------------- Proposal ------------ 2010-03-26 -------------------------------------------------
##Proposed Resolution: Fixed The revised specification text is included in the 10_process-data - Issue 311.doc. ---------------------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 14/May/10 03:51 PM ] |
| Spec-Draft3-review |
| Comment by Ivana Trickovic [ 14/May/10 03:52 PM ] |
|
The following changes should be made:
(1) pdf, page 196 change "The Data Input is an item-aware element. Data Inputs MAY be visualized in a Process diagram to show the inputs to the top-level Process..." to "The Data Input is an item-aware element. Data Inputs are are visually displayed on a Process diagram to show the inputs to the top-level Process..." (2) pdf, page 198 change "The Data Output is an item-aware element. Data Output MAY be visualized in a top-level Process diagram to show the outputs..." to "The Data Output is an item-aware element. Data Output are visually displayed on a top-level Process diagram to show the outputs..." |
| Comment by Ivana Trickovic [ 17/May/10 03:22 PM ] |
|
As per the meeting of May 17th: Agreed that this needs to be fixed
Steve to check the missing text |
| Comment by Stephen White [ 18/May/10 04:05 PM ] |
| Done |
| Comment by Falko Menge [ 09/Jun/10 10:34 AM ] |
|
spec-May24-review
There are two typos in the application of item (e). Proposal: Replace 'accesibility' with 'accessibility' in the headline below Table 10.57 and in the first sentence of the second paragraph. |
[BPMNFTF-310] [OMG 14645] Missing details regarding the visualisation of a DataState for a DataObject
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Ivana Trickovic |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
Name: Denis Gagne
Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 10.3.1 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 213 Title: Missing details regarding the visualisation of a DataState for a DataObject Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: The section discussing States of DataObject at the bottom of page 213 refers to Figure 7-8 to examplify the visualization of a DataState attribute of a DataObject but fails to specify the details of this visualizaton (i.e. in this particular case using square brackets surrounding the DataState value). Or is the visualization left to the vendor tool? |
| Comments |
| Comment by Ivana Trickovic [ 18/Mar/10 10:33 AM ] |
| proposalScheduledForBallot11 |
| Comment by Ivana Trickovic [ 13/Apr/10 02:49 AM ] |
|
-------------------- Proposal ---------- 2010-04-13 -------------------------------------
##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposals for OMG 15080 ( |
| Comment by Stephen White [ 13/Apr/10 01:11 PM ] |
|
It doesn't look like either |
[BPMNFTF-309] [OMG 14644] Missing DataStore from the enumeration of item-aware
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne, dgagne@trisotech.com)
Specification: BPMN 2.0 Section: 10.3.1 FormalNumber: beta 1 Version: v 0.9.14 RevisionDate: may 22 Page: 212 Title: Missing DataStore from the enumeration of item-awre elements at top of the page Nature: Clarification Severity: Minor Description: The first para at the top of page 212 lists the possible item-aware elements but is missing the DataSore as per the class diagram below it Figure 10-46 ------------------------ New Proposed Resolution ----------- 2010-01-21 ---------------------------- ##Proposed Resolution: Fixed Section 10.3,1 Sub-Section "Item-Aware Elements," page 182 (212 pdf), last sentence on page: add "Data Stores" to list of elements in the sentence. ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 21/Jan/10 09:15 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-21 ----------------------------
Section 10.3,1 Sub-Section "Item-Aware Elements," page 182 (212 pdf), last sentence on page: add "Data Stores" to list of elements in the sentence. ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-308] [OMG 14641] Merge Conversation and Collaboration
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| File Attachments: |
Collaboration Metamodels.doc
|
||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: 11 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 293 Title: Merge Conversation and Collaboration Nature: Revision Severity: Significant Description: Conversation and Collaboration currently differ because Conversation messages can grouped, and Conversation can be reused. Since these capabilities are useful on collaboration, it would be simpler for users and implementers to merge these diagrams. Then there would be two interactions diagrams, one highlighting communication between participants (collaboration/conversation) and one highlighting the sequence of message flow (Choreography). This would be easier to explain and reduce the terminology complexity of the "three C models". ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 19/Nov/09 04:54 PM ] |
|
---------- Discussion during Interaction Sub-Group on 2009-11-19 ----------
We reviewed the current metamodel proposal. The Choreography metamodel was updated to reflect the changes of the Collaboration metamodel. We will delete the ConversationAssociation class of the Collaboration metamodel. It is no longer needed with the merging of the two models. Now we should have the same functionality as is in the Beta version, but with one diagram (Collaboration) instead of two. We will start the review of the text changes that will be required and put together the full proposal. Discussion regarding the hierarchy of Conversation, including the use of Call Conversations did not result in any metamodel changes. Although a new issue will be generated about adding a multi-instance marker to Conversation Nodes. |
| Comment by Stephen White [ 19/Nov/09 06:42 PM ] |
| "Collaboration Metamodels.doc" is a file that contains the draft revisions to the Collaboration and Choreography metamodels that is a result of the merging of the Conversation and Collaboration diagram proposal. |
| Comment by Stephen White [ 22/Mar/10 01:08 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 22/Mar/10 07:46 PM ] |
| Reduced Priority from Critical to Major |
[BPMNFTF-307] [OMG 14623] Conversation Muddle
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction, Metamodel, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
##source: IBM (Steve White wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: 11 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 293 Title: Conversation Muddle Nature: Revision Severity: Significant Description: The concept of conversation is muddled in the idea of a logical grouping of message flow and a diagram that contains a set of these groupings. Conversations should be a light-weight element defined to be used in any diagram that has message flow. ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 19/Nov/09 06:53 PM ] |
|
The new proposal to merge Collaboration and Conversation makes the GlobalCommunication rather obsolete. The GlobalCommunication is now just a light-weight Collaboration--it has Participants, MF, and Correlation.
This element should be removed or converted into a re-usable Conversation -- just a name and correlation. |
| Comment by Mariano Benitez (Oracle) [ 08/Dec/09 01:11 PM ] |
|
-------------------- FTF Meeting ----------- 2009-12-08 ---------------------------------
Agreed to defer until merging of conversation and collaboration is resolved |
| Comment by Stephen White [ 22/Mar/10 05:13 PM ] |
| New Proposed Resolution |
[BPMNFTF-306] [OMG 14622] Correlation on Choregraphy
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##source: NIST (Conrad Bock conrad.bock@nist.gov)
Specification: BPMN 2 Beta 1 Section: Choreography FormalNumber: dtc/09-08-01 Version: RevisionDate: Page: Title: Correlation on Choregraphy Nature: Revision Severity: Significant Description: It should be possible to add correlation to choreography, without creating a conversation. Sometimes interactions are only described with choreograpies, and they might need correlation. ##Proposed Resolution: Duplicate The resolution to this issue was resolved through Issue 14654 ( |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 08/Dec/09 01:08 PM ] |
|
-------------------- FTF Meeting ----------- 2009-12-08 ---------------------------------
Agreed to defer until merging of conversation and collaboration is resolved |
| Comment by Conrad Bock (NIST) [ 19/Mar/10 01:39 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-305] [OMG 14617] Typo in Section 7.2 paragraph 1
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: TIBCO Software (Justin Brunt jbrunt@tibco.com)
Specification: Business Process Model and Notation (BPMN) Section: 7.2 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 14 Title: Typo in Section 7.2 paragraph 1 Nature: Clarification Severity: Minor Description: The second sentence of the first paragraph in section 7.2 states: "The goal of the specification is to enable portability of Process definitions, so that users can take Process definitions created in one vendor's environment and use them is another vendor's environment." The final part of the sentence should read "and use them in another vendor's environment." i.e. "is" should become "in" -------------------- Proposal ----------- 2009-11-17 --------------------------------- ##Proposed Resolution: Fixed Section 7.1, page 14 (page 44 pdf), first paragraph, second sentence: change "use them is another" to "use them in another" ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 17/Nov/09 09:36 PM ] |
|
-------------------- Proposal ----------- 2009-11-17 ---------------------------------
Section 7.1, page 14 (page 44 pdf), first paragraph, second sentence: change "use them is another" to "use them in another" ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-304] [OMG 14616] URL referenced for XPDL specification is incorrect
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: TIBCO Software (Justin Brunt jbrunt@tibco.com)
Specification: Business Process Model and Notation (BPMN) Section: 3.2 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 9 Title: URL referenced for XPDL specification is incorrect Nature: Clarification Severity: Minor Description: The URL used to reference the XPDL specification is incorrectly given as http://www.wfmc.org/standards/docs.htm Instead I would suggest either http://wfmc.org/wfmc-standards-framework.html or http://www.wfmc.org -------------------- Proposal ----------- 2009-11-17 --------------------------------- ##Proposed Resolution: Fixed Section 3.2, page 10 (page 40 pdf), sub-section "XPDL:" change reference to: "http://wfmc.org/wfmc-standards-framework.html" ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 17/Nov/09 09:30 PM ] |
|
-------------------- Proposal ----------- 2009-11-17 ---------------------------------
Section 3.2, page 10 (page 40 pdf), sub-section "XPDL:" change reference to: "http://wfmc.org/wfmc-standards-framework.html" ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-303] [OMG 14615] URL referenced for WfMC Gloassary is incorrect
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: TIBCO Software (Justin Brunt jbrunt@tibco.com)
Specification: Business Process Model and Notation (BPMN) Section: 3.2 FormalNumber: dtc/2009-08-14 Version: FTF Beta 1 for Version 2.0 RevisionDate: August 2009 Page: 8 Title: URL referenced for WfMC Gloassary is incorrect Nature: Clarification Severity: Minor Description: The URL given for the WfMC Gloassary in section 3.2 is incorrectly shown as http://www.wfmc.org/standards/docs.htm I would suggest that either http://wfmc.org/wfmc-standards-framework.html or just http://www.wfmc.org is used. -------------------- Proposal ----------- 2009-11-17 --------------------------------- ##Proposed Resolution: Fixed Section 3.2, page 8 (page 38 pdf), sub-section "WfMC Glossary:" change reference to: "http://wfmc.org/wfmc-standards-framework.html" ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 17/Nov/09 09:25 PM ] |
|
-------------------- Proposal ----------- 2009-11-17 ---------------------------------
Section 3.2, page 8 (page 38 pdf), sub-section "WfMC Glossary:" change reference to: "http://wfmc.org/wfmc-standards-framework.html" ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-301] [OMG 14614] Example of Lane, Laneset, and Partitions
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Examples |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##source: IBM (Steve White wstephe@us.ibm.com)
Notification: No Specification: BPMN 2.0 Beta Section: 10.7 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 282 Title: Example of Lane, Laneset, and Partitions Nature: Clarification Severity: Significant Description: Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects. |
| Comments |
| Comment by Stephen White [ 17/Nov/09 09:14 PM ] |
| The SoaML Sub-Group is working with an example that proposes to use Conversations as the basis for Lanes. We might be able to use this as the example, or at least demonstrate that this can be done. |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:52 PM ] |
| We should also have an example using Resources, since this is the most common usage of Lanes. |
| Comment by Stephen White [ 30/Nov/09 07:16 PM ] |
|
---------- Discussion during BPMN FTF Call on 2009-11-30 ----------
We definitely need examples SoaML not ready, but we could use. We shoud use an example with resources Denis: we should use a mixed example to show the flexibility and possiblities Thus, We need a few examples. How do we do that in the spec? It might be a larger appendix Example sub-team should do this. Action: create Example component in JIRA (mariano) - done Assign to Examples sub-group through Component. (done) |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 03:18 PM ] |
| New Proposed Resolution |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 03:18 PM ] |
|
##Proposed Resolution: Deferred
Examples are required but are non-normative, so we can defer. |
[BPMNFTF-300] [OMG 14589] Definition of Participant Band Shadings not clear
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Steve White wstephe@us.ibm.com)
Specification: BPMN 2.0 Beta Section: 12 FormalNumber: DTC-09-08-14 Version: Beta RevisionDate: Aug 09 Page: 314 Title: Definition of Participant Band Shadings not clear Nature: Clarification Severity: Significant Description: The participant bands of Choreography Activities have different shadings, but chapter 12 does not define the shadings or the reasons. The differences are shown in a figure, but not defined in the text. ##Proposed Resolution: Fixed (a) Section 12.4.1, page 316 (346 pdf): Add the following diamond bullet prior to Figure 12.8: "The Participant Band of the Participant that does not initiate the interaction MUST be shaded with a light fill." (b) Section 12.4.2, page 322 (352 pdf): Add the following diamond bullet prior to Figure 12.17: "The Participant Band of a Participant that does not initiate the interaction MUST be shaded with a light fill." |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 08/Dec/09 01:05 PM ] |
|
-------------------- FTF Meeting Dec-08-2009 ---------------------------------
we agree that we need to add text in the spec in the same way as it is done for Tasks. The description of the visual clues (shading, etc) must be described properly for choreography tasks. Steve will prepare the proposal. |
| Comment by Stephen White [ 22/Mar/10 06:00 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-299] [OMG 14579] Variable Id TO Variation Id
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Red Hat (Gary Brown gbrown@redhat.com)
Page 326 of pdf: para below Figure 11.4 refers to "(keyed on Variable Id and Order Id)", however the figure 11.4 uses Variation ID and Order ID. Proposal: change "Variable Id" in paragraph to "Variation Id". -------------------- Proposal ----------- 2009-11-17 --------------------------------- ##Proposed Resolution: Fixed Section 11, page 296 (page 326 pdf), first paragraph after Figure 11.4, second sentence: change "Varable ID" to "Variation ID" ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 17/Nov/09 09:43 PM ] |
|
-------------------- Proposal ----------- 2009-11-17 ---------------------------------
Section 11, page 296 (page 326 pdf), first paragraph after Figure 11.4, second sentence: change "Varable ID" to "Variation ID" ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-298] [OMG 14568] The schema for globalTasks of type Send ,Receive and Service are not there
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Specification: BPMN Section: 10.2.9 FormalNumber: BPMN 2.0 schema Version: v 0.9.14 RevisionDate: may 22 Page: pp205-210 Title: The schema for globalTasks of type Send ,Receive and Service are not there Nature: Revision Severity: Critical Description: In the semantic.xsd and in the spec document chapter 10.2.7 vs chapter 10.2.9. The schemas for the globalSendTask, globalReceiveTask and globalSendTask are missing. This is related to another reported issue that the class diagram Figure 10-40 on page 199 is also missing these corresponding classes. -----Proposal---------------- F2F 03/09/2010 ------------------------- ##Proposed Resolution: Duplicate/Merged The resolution of this issue is covered by |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 03:09 PM ] |
| There did not appear to be much re-use likelihood or re-use value in send, receive or service tasks. Hence global versions of those activities were omitted (deliberately, not accidentally). |
| Comment by Mariano Benitez (Oracle) [ 27/Nov/09 03:51 PM ] |
|
I agree this elements should appear in the specification, and modeled properly.
For the sake of completeness and consistency, and because I don't think we should rule out case just because we think they are probably not reusable. An easy example would be that you could start having a global manual task, and then replace the implementation with a global service task. |
| Comment by Stephen White [ 30/Nov/09 07:08 PM ] |
|
---------- Discussion during BPMN FTF Call on 2009-11-30 ----------
There were two basic viewpoints expressed on the call (and in the comments) One is that there appears to be no need to include Send, Receive, and Service Tasks for Global Tasks. The other is that there are reasons to do so: 1) It doesn't really cost anything to add them (just 3 mm classes and schema elements) 2) We need to support the potential evolution of models where a call to one type of Global Task might need to change to one of the three that are missing. 3) There might be template models defined to call various types, including services, which can just be plugged in. Mariano will take the lead on this issue and he and Denis will come up with a proposal to include the three Global Tasks. We could have a counter proposal to close with no change. |
| Comment by Suzette Samoojh (IBM) [ 01/Dec/09 05:13 PM ] |
|
Regarding the following:
1) It doesn't really cost anything to add them (just 3 mm classes and schema elements) I disagree. There is cost to the tool vendors that have to support these elements. And there is cost to users that must deal with more concepts. Regarding the evolution of a global manual task into a global service task, I don't understand the scenario. The Service (aka Interface) itself is global. The Global Manual Task can be converted into a Service (i.e. Interface). And the CallActivity to a Service Task. What additional information needs to be captured that necessitates a global Service Task in addition to the global Service? If we added a Global Service Task, my fear is we are introducing unnecessary complexity. Instead of a Service Task calling a global Service, we now have a Call Activity calling the Global Service Task calling the Service. So several levels of indirection. With of course the need to keep all of their IOSpecifications in-synch. So I see additional complexity for tools and users, but I don't see a whole lot of payback. Or maybe I don't sufficiently understand the use-case. Can you expand on the use-case ... what am I missing? |
| Comment by Mariano Benitez (Oracle) [ 17/Dec/09 12:03 PM ] |
|
My primary concern is ease of understanding and very simple reuse with reasonable isolation.
1) A user could discover that an activity (of any kind) could be reused in othere places. That activity will carry the internal mappings and the vendor implementation. If I need to think different ways of doing this based on the activity type, I would feel confused. Actually as a tool vendor, I would just create a single "Transform to Global Task" action for any local activity. 2) I could define a GlobalTask of one kind, use it extensively in many processes, and later I decide to change the type to another one (say human to service). Why should I choose different ways of reusing? From a vendor perspective, I would allow changing the type without letting the user worry about the impact. 3) Also from an encapsulation perspective, I would choose to provide a GlobalTask with a given iospecification, and other people would use it without worrying about the implementation type. 4) From a tooling perspective, it really adds quite some value to have a unified way of doing things. Specially from an end-user perspective. People do not really care how many indirection levels are there as long as they get what they need. 5) to expand on the the case of transforming a manual to a service, you described that people would need to "modify" ALL the processes that use the global task. In my case just the global task is modified, all the rest is left unmodified. I really do prefer modify only one thing. Hope this use cases clarify my reasons to propose this resolution. |
| Comment by Mariano Benitez (Oracle) [ 04/Mar/10 02:31 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 09/Mar/10 07:40 AM ] |
|
As per March F2F Meeting:
- This is an editorial issue - This issue is related to |
[BPMNFTF-297] [OMG 14564] Choreography Logic Issues
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Replacement for Figure 12.36.jpg
Replacement for Figure 12.37.jpg
|
| Description |
|
##Source: GWT TUD GmbH (Frank Töppel Toeppel.Frank@mailbox.tu-dresden.de)
maybe I'm wrong, but it seems there's a logic error in the PDF document mentioned above: - Figure 12.36 shows a Choreography starting with communication from A (initiator) to B. Depending on message content based decision next message will be sent from A to B (decision YES) or from A to C (decision NO). - Comparing that to the corresponding Collaboration in Figure 12.37 I detected a mismatch, within Pool A the gateway acts inverse: If decision YES message M3 will be sent from A to C, and if decision NO message will be sent from A to B - Looks like content of pool A should be adapted (decision YES should result in message from A to B) Furthermore there seems to be an offset to Figure indices listed in some chapters vs. the real Figure numbers: - Check chapter 10.2.8 (Loop Characteristics in Process diagrams) - Scroll to page 169 (PDF document page 199), chapter Standard Loop Characteristics - You will find a link to Figure 10.42 and 10.43 (see Figure 10.42 and Figure 10.43) - Corresponding figures instead are 10.43 and 10.44 - This offset stuff starts somewhere before in the document, maybe an additional picture has been added Besides that I really enjoy reading that well structured specification, very often to verify whether the used BPM suite fits to the defined standards. ---------------------- Proposal ---- 2009-12-10 ------------------------------- ##Proposed Resolution: Fixed (a) Replace Figure 12.36 with a figure that has the positioning of the Participants in the Participant Bands more consistent. See here: http://www.osoa.org/jira/secure/attachment/10570/Replacement+for+Figure+12.36.jpg (b) Replace Figure 12.37 with a figure that sequence of activities are matching those of Figure 12.36. See here: http://www.osoa.org/jira/secure/attachment/10571/10571_Replacement+for+Figure+12.37.jpg (c) Section 10.2.8 Loop Characteristics, Sub-Section Standard Loop Characteristics, page 169 (199 pdf), first bullet in section: replace "Figure 10.42" with "Figure 10.43" and replace "Figure 10.43" with "Figure 10.44." ----------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 10/Dec/09 05:40 PM ] |
|
---------------------- Proposal ---- 2009-12-10 -------------------------------
(a) Replace Figure 12.36 with a figure that has the positioning of the Participants in the Participant Bands more consistent (b) Replace Figure 12.37 with a figure that sequence of activities are matching those of Figure 12.36 (c) Section 10.2.8 Loop Characteristics, Sub-Section Standard Loop Characteristics, page 169 (199 pdf), first bullet in section: replace "Figure 10.42" with "Figure 10.43" and replace "Figure 10.43" with "Figure 10.44." ----------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-296] [OMG 14559] Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD)
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Moffat | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Lombardi (Alex Moffat Alex.Moffat@lombardi.com)
Subject: Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) Summary: There is currently a mismatch between the target namespace of the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) themselves. This applies to Beta 1. In the PDF specification that are several instances where the target namespace for the XML Schemas is defined as "<http://www.omg.org/bpmn20>http://www.omg.org/bpmn20": - Table 8.2 (page 44) - Table 8.16 (page 53) - Table 10.19 (page 150) However the latest available XML Schemas (bmi/09-05-05) have the target namespace set to "<http://schema.omg.org/spec/BPMN/2.0>http://schema.omg.org/spec/BPMN/2.0". If the XML Schemas are correct then the specification should reflect the same target namespace. ------------------------ New Proposed Resolution ----------- 2010-01-24 ---------------------------- ##Proposed Resolution: Fixed (a) Table 8.2, page 44 (74 pdf), first row, second column: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (b) Table 8.16, page 53 (83 pdf), forth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (c) Table 8.16, page 53 (83 pdf), fifth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (d) Table 8.16, page 53 (83 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (e) Table 10.19, page 150 (180 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" Note on 2010-04-26: The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be: - http://www.omg.org/spec/BPMN/20100524/MODEL for the semantic model XML Schema - http://www.omg.org/spec/BPMN/20100524/MODEL-XMI for the semantic model XMI - http://www.omg.org/spec/BPMN/20100524/DI for diagram interchange XML Schema - http://www.omg.org/spec/BPMN/20100524/DI-XMI for diagram interchange XMI xsds |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 03:00 PM ] |
|
The target namespace in the XSD is the correct one.
As a general rule-of-thumb, the XSD is the 'master', while the snippets in the spec are copies. When they don't match, use what is in the XSD. But the snippets in the spec do need to be updated. |
| Comment by Stephen White [ 24/Jan/10 09:26 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-24 ----------------------------
(a) Table 8.2, page 44 (74 pdf), first row, second column: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (b) Table 8.16, page 53 (83 pdf), forth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (c) Table 8.16, page 53 (83 pdf), fifth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (d) Table 8.16, page 53 (83 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" (e) Table 10.19, page 150 (180 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0" ------------------------------------------------------------------------------------------------------------------------ |
| Comment by Pete Rivett [ 03/Mar/10 06:56 PM ] |
|
Actually the XSD does *not* have the correct one - in that it's in violation of OMG policy on this matter, which is documented in smsc/09-09-07
In summary this mandates the URI to be something starting: http://www.omg.org/spec/BPMN/yyyymmdd Given that there are 2 different XML-based formats for BPMN 2.0 then something is needed to distinguish them. 'XSD' is not sufficient since XMI also provides for generating XSDs. It seems to me the difference is that the XSD in the spec is authored rather than being generated (by XMI). Regardless of the actual term, the namespaces would then be, for example: http://www.omg.org/spec/BPMN/yyyymmdd/authored and: http://www.omg.org/spec/BPMN/yyyymmdd/xmi Note that the XMI nsURI and prefix need to also be added as MOF Tags to the formal metamodel. |
| Comment by Tom Rutt [ 22/Apr/10 04:36 PM ] |
|
This proposal is not aligned with the smsc namespace policy http://www.omg.org/members/cgi-bin/doc?smsc/09-09-07.pdf
The BPMN version is not used in the namespace url, the date is used instead. This way future bpmn versions can extend the existing namepace, rather than requiring a new one for compatible changes. Also, the namespace for the xmi xsd should be different form the namespace for the bpmn specific xsd. Also, we should to have namespaces consistent with the bpmn DI namespaces. T hese require a suffix for each specific schema within the BPMN 2 set. I propose that the namespace for the BPMN metamodel (bpmn specific) xsd be: • http://www.omg.org/spec/BPMN/20100626/MODEL the namespace for the xmi schema for the metamodel should be • http://www.omg.org/spec/BPMN/20100626/MODEL-XMI I have put a similar comment on the DI issue. |
| Comment by Ivana Trickovic [ 17/May/10 03:43 PM ] |
|
As per the meeting of May 17th: See issue |
| Comment by Falko Menge [ 08/Jun/10 06:51 PM ] |
|
spec-May24-review
Table 10.19 has been changed to use xmlns="http://http://schema.omg.org/spec/BPMN/2.0", which is neither the correct namespace nor a valid URI. Proposal: Replace 'http://http://schema.omg.org/spec/BPMN/2.0' with 'http://www.omg.org/spec/BPMN/20100524/MODEL' in the 'xmlns' attribute of the 'definitions' element. |
| Comment by Ivana Trickovic [ 11/Jun/10 10:59 AM ] |
|
spec-May24-review
[AB feedback] Feedback from Steve Cook, Microsoft: Resolution 14559 (and some others) acknowledge a difference between the proposed XML namespaces and the OMG namespace guidelines. It is not clear to me what conventions are actually being adopted for the spec - are the OMG guidelines actually being followed? |
| Comment by Ivana Trickovic [ 11/Jun/10 10:59 AM ] |
|
As per the 6/7 meeting:
- In the response state that the specification follows OMG guidelines and point to the related issue - Fix remaining incorrect namespaces (see table 10.19 and section 15.3.1 BPMN DI namespace) |
[BPMNFTF-295] [OMG 14551] Allow Choreography Task to have more than 2 Participants
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Stephen A. White wstephe@us.ibm.com)
******************************************************************************* Name: Stephen A. White Company: IBM mailFrom: wstephe@us.ibm.com Notification: No Specification: BPMN 2.0 ection: Ch. 12.4.1 FormalNumber: dtc-09-08-14 Version: Beta 1 RevisionDate: August 2009 Page: 316 Title: Allow Choreography Task to have more than 2 Participants Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: A Choreography Task now can have only two Participants. But there are situations where one Participant may send the same message to more than one other Participant. Multiple Choreography Tasks would be needed to do this, where it could be done with one if this change was made. -------------------- Proposal ----------- 2009-12-04 --------------------------------- ##Proposed Resolution: Close; no change The available use cases for this issue are not strong enough to change the specification. ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 04/Dec/09 09:43 AM ] |
|
---------- Discussion during Interaction Sub-Group on 2009-12-03 ----------
We did not think that there were any use cases strong enough to change the characteristics of Choreography Tasks at this time. Thus, we will recommend to close, with no change. |
| Comment by Stephen White [ 04/Dec/09 09:46 AM ] |
|
-------------------- Proposal ----------- 2009-12-04 ---------------------------------
Close; no change. The available use cases for this issue are not strong enough to change the specification. ------------------------------------------------------------------------------------------------ |
[BPMNFTF-294] [OMG 14548] Clarification on relationship between MEP and Choreography Task in BPMN2
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Gary Brown |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Red Hat (Gary Brown gbrown@redhat.com)
Description: PDF page 337, page 307: "A single MEP is defined as a BPMN Choreography Task (see page 350). Thus, a Choreography defines the order in which Choreography Tasks occur. Choreography Sub-Processes allow the composition/decomposition of Choreographies." If the MEP has a request, response and multiple faults how will the choreography identify which subsequent path based on a decision relates to each response. Would propose changing wording to "A single MEP can be defined ..." - allowing an MEP to be defined across separate Choreography Tasks, enabling the decision point and relevant paths based on each response type to be explicitly defined in the choreography. However this may require some additional mechanism to correlate the separate choreography tasks as belonging to the same MEP. -------------------- Proposal ----------- 2009-12-17 --------------------------------- ##Proposed Resolution: Fixed PDF page 337, page 307: Change: "A single MEP is defined as a BPMN Choreography Task" To: "A single MEP can be defined as a BPMN Choreography Task" ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Gary Brown [ 17/Dec/09 04:15 PM ] |
|
Proposal:
PDF page 337, page 307: Change: "A single MEP is defined as a BPMN Choreography Task" To: "A single MEP can be defined as a BPMN Choreography Task" |
| Comment by Stephen White [ 17/Dec/09 08:28 PM ] |
|
--------------------------- Discussion during Conference Call on 2009-12-03 -----------------------
More complicated MEPs. How do we do that? How do we identify them? Break up the more complicate ones into multiple activities? Shouldn't be tied to MEPs? Should we identify the MEP? How would we point to them? What if there is more than two? Should we restrict it to two? Or just soften text? CDL only had a couple MEPs Action: Gary to make proposal --------------------------------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 17/Dec/09 08:28 PM ] |
|
--------------------------- Discussion during Conference Call on 2009-12-17 -----------------------
Close now with simple changes. Allow multiple Message Flow as now Or restrict to 1 or 2 Fix wording now and submit separate issue on how many Message Flow a Choreography Task should have. Action: Gary will submit text change and open a new issue. --------------------------------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-293] [OMG 14546] Initiating message flow for ChoreographyTask
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Conrad Bock (NIST) | Assigned To: | Conrad Bock (NIST) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: BPMN 2 Beta Section: FormalNumber: Version: RevisionDate: Page: Title: Initiating message flow for ChoreographyTask Nature: Revision Severity: Minor test: 3qw8 B1: Report Issue Description: In BPMN Core Structure, Common Elements, Message, second figure, text underneath refers to a list of messages for a choreography task, but the association between ChoreographyTask and MessageFlow is not ordered. Or the initial message flow of a Choreography Task could be identified by a new association if it is not intended to order all the messages. ##Proposed Resolution: Fixed Choreography Tasks can have at most two message flows, with one participant per message flow, see resolution of issue Under Figure 8.29 (A non-initiating Message), replace the bullet sentence with "Any Message sent by the non-initiating Participant or SubChoreography MUST be shaded with a light fill. |
| Comments |
| Comment by Conrad Bock (NIST) [ 21/Mar/10 09:03 AM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 06/Apr/10 02:47 PM ] |
|
-----------Proposal----------------Apr 6, 2010---------------------------
##Proposed Resolution: Fixed Choreography Tasks can have at most two message flows, with one participant per message flow, see resolution of issue 14890]. The initiating message flow can be identified from the initiating participant Under Figure 8.29 (A non-initiating Message), replace the bullet sentence with "Any Message sent by the non-initiating Participant or SubChoreography MUST be shaded with a light fill. |
[BPMNFTF-292] [OMG 14543] Issues regarding properties in the Activity attribute table
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: Table 10-3 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 161 Title: Page 161, Table 10-3, Issues regarding properties in the Activity attribute table Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Page 161, Table 10-3, Issues regrading properties: 1)The text describes properties as being "local" to the activity, yet contibues to mentione a deliation with the activity name as a prefix. If it is local why would we need the activity name as a prefix? 2) Although I uderstand using the name of the peorperty for presentation in a tool interface, we do not have a guarantee that the name will be unique. -------------------- Proposal ----------- 2009-12-02 --------------------------------- ##Proposed Resolution: Fixed (a) Table 10.3, description for the Properties attribute, page 129 (159 pdf), second sentence: Change " "local" to" to "contained within" (b) Table 10.3, description for the Properties attribute, page 129 (159 pdf): delete third sentence (c) Table 10.1, description for the Properties attribute, page 125 (155 pdf), second sentence: Change " "local" to" to "contained within" (d) Table 10.1, description for the Properties attribute, page 129 (159 pdf): delete 4th and 5th sentence ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 02/Dec/09 03:22 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-12-02 ----------
Activity attributes should be referenceable. Are they truly local? Fully delineated is used for user purposes, but tool would reference in its own way. Names of referenced properties must be unique within the activity? That would be special for properties. The section on usage of data with XPath Expressions shows how to do this. Proposal: Remove the sentence about "local". Changed to "contained in" Remove last sentence. Action: Write up proposal |
| Comment by Stephen White [ 02/Dec/09 04:13 PM ] |
|
-------------------- Proposal ----------- 2009-12-02 ---------------------------------
(a) Table 10.3, description for the Properties attribute, page 129 (159 pdf), second sentence: Change " "local" to" to "contained within" (b) Table 10.3, description for the Properties attribute, page 129 (159 pdf): delete third sentence (c) Table 10.1, description for the Properties attribute, page 125 (155 pdf), second sentence: Change " "local" to" to "contained within" (d) Table 10.1, description for the Properties attribute, page 129 (159 pdf): delete 4th and 5th sentence ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 07/Dec/09 12:30 PM ] |
|
I have a comment, that might end up in a new issue, but it applies to this resolution too:
While I agree that activity properties are contained in the activity, we should make clear if those properties are in the scope of the entire process instance, of each token can get a new copy of the values. This is particularly important to define when embedded subprocesses are used. Well, on second thought, they should follow the same pattern as data objects. So, to describe activity properties by comparison, we could say that they have the same scope of data objects defined in the same process / sub-process, but qualified by the activity. Can you confirm this? |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-291] [OMG 14542] The "property" class is not depicted in the class diagram Figure 10-6
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Update to Figure 10.6.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Specification: BPMN 2.0 Section: Figure 10-6 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 160-161 Title: Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram Figure 10-6 Nature: Clarification Severity: Minor Description: Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram (Figure 10-6) but listed in the attribute (Table10-3). -------------------- Proposal ----------- 2009-11-22 --------------------------------- ##Proposed Resolution: Fixed Figure 10.6 will be updated to include the Property class. The updated figure is shown here: http://www.osoa.org/jira/secure/attachment/10562/10562_Update+to+Figure+10.6.jpg. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 22/Nov/09 09:04 PM ] |
|
-------------------- Proposal ----------- 2009-11-22 ---------------------------------
Figure 10.6 will be updated to include the Property class. The updated figure is shown in the attached image. ----------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-290] [OMG 14541] Error in attribute name. "resources" should be "activityResource"
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: Table 10-3 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 161 Title: Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource" Nature: Revision Severity: Minor test: 3qw8 B1: Report Issue Description: Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource" ---------------------- Proposed Resolution -------- 2010-04-02 --------------------- ##Proposed Resolution: Duplicate The resolution of Issue 14710 will resolve this issue |
| Comments |
| Comment by Stephen White [ 02/Dec/09 03:22 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-12-02 ----------
ActivityResource is usage of resource. More like ResourceRequirement. So, resources attribute seems strange since it doesn't point to Resource Rename ActivityResource? ResourceRole? Should be contextual to activity. No org model hook? Should we have an org model hook? Resource now serves as org model hook. Change the name of resource attribute? Lanes point to ActivityResource now. There is an example. But Lanes can point to anything. No org model. How do we assign departments to activities? Have to use Resource. ActivityRequirement; ResourceAssignements? ActivityResource is an abstract But it doesn't fit with the concrete sub-classes (which are roles) But we don't want to confuse the role the resource plays for the activity with the roles they play in the organization. Can't use Participant Should we deal with Resource element first? We will this wait on this issue until we deal with other issues. Action: create an issue assign org info to activities and an issue about Performers |
| Comment by Stephen White [ 22/Mar/10 05:57 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 02/Apr/10 04:59 PM ] |
| New Proposed Resolution |
[BPMNFTF-289] [OMG 14540] MultiInstance Activity: Potential error and clarification regarding BehaviorEventRef
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Hagen Volzer |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
Name: Denis Gagne
Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: Table 10-26 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 204 Title: Page 204, Table 10-26, MultiInstance Activity: Potential error and clarification regarding **BehaviorEventRef Nature: Clarification Severity: Critical test: 3qw8 B1: Report Issue Description: Page 204, Table 10-26, There seems to be an error in providing an attribute called noneBehaviorEventRef, it should be allBehaviorEventRef....? Futhermore a complexBehaviorEventRef attribute would be missing....? But why do we need multiple ***BehaviorEventRef attributes? Couldn't we just have a BehaviorEventRef attribute that is used for either one, all or complexe? ##Proposed Resolution: Close, No change. There is no issue. The questions in the issue description probably arose from a misunderstanding of the "complex" MI behavior, which refers to multiple event descriptions and not necessarily a single one as assumed by the reporter. When behavior is complex, we have multiple event refs, so we cannot unify with the other two options. "none" and "one" could indeed be unified; but it would be clearer not to unify. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:28 PM ] |
|
As per March F2F Meeting:
- Need to be addressed. To be assigned to Matthias. |
| Comment by Stephen White [ 24/Mar/10 07:50 PM ] |
|
As per Conference Call on 2010-03-24
Assign to Hagen for potential inclusion on Ballot 11 |
| Comment by Stephen White [ 24/Mar/10 07:51 PM ] |
| proposalScheduledForBallot11 |
| Comment by Hagen Volzer [ 30/Mar/10 08:56 AM ] |
|
>Page 204, Table 10-26, There seems to be an error in providing an
>attribute called noneBehaviorEventRef, it should be >allBehaviorEventRef....? Futhermore a complexBehaviorEventRef >attribute would be missing....? "noneBehaviorEventRef" is correct; it is thrown when behavior is set to "none", if behavior is set to "all" no event is thrown; the events that can be thrown when behavior is set to "complex" are captured in the complexBehaviorDefinition: >But why do we need multiple ***BehaviorEventRef attributes? Couldn't >we just have a BehaviorEventRef attribute that is used for either >one, all or complexe? When behavior is complex, we have multiple event refs, so we cannot unify with the other two options. "none" and "one" could indeed be unified; but maybe it is clearer not to unify? This issue can be closed with no change. |
| Comment by Hagen Volzer [ 07/Apr/10 11:48 AM ] |
|
##Proposed Resolution: Close, No change.
There is no issue. The questions in the issue description probably arose from a misunderstanding of the "complex" MI behavior, which refers to multiple event descriptions and not necessarily a single one as assumed by the reporter. More explanation is found in the previous comment. |
[BPMNFTF-288] [OMG 14539] MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupting
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Hagen Volzer |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: Table 10-26 FormalNumber: BPMN 2.0 Version: v 0.9.14 RevisionDate: may 22 Page: 203 Title: Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupting Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Page 203, Table 10-26, multiInstanceLoopCharacteristics: I believe that the motivation behind having events thrown in coordination with the completion of instances of multiInatnce activity is to have non-interrupting boundary events to carry out some desired ackownledgements (or other defined activites), but if the catching boudnary event is interrupting, the alternate flow will be followed potentially resulting in un-expected or suspected behavior. What is the intended use case if the catching boudnary event is interrupting? ##Proposed Resolution: Close, No Change The design of the MI activity was done with the use case in mind that the catching boundary event is non-interrupting. However, we do not see a strong reason to rule out that the catching boundary event could be interrupting. |
| Comments |
| Comment by Stephen White [ 18/Nov/09 03:38 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-18 ----------
Interrupting Multi-Instance Activities? Perhaps an example should be spelled out. This might be modeled with a completion condition also. The main use case might be for non-interrupting Events (even though these are a new feature). Hagen will take the issue. |
| Comment by Hagen Volzer [ 27/Nov/09 03:17 AM ] |
|
>What is the intended use case if the catching boudnary event is interrupting?
We never considered that. The intended use case for this MI configuration is that these boundary events are non-interrupting so that remaining inner instances will continue executing. Nevertheless I don not see a strong reason for ruling out these events being interrupting. |
| Comment by Stephen White [ 01/Dec/09 09:06 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-25 ----------
Hagen looked into it. Multi-Instance, complex behavior Trigger events from inside Caught by boundary. The use case was non-interrupting, and then continue working. Then a completion condition, which stops all remaining activities. V2.0 changed the behavior that existed in V1.2 What about interrupting? Errors should interrupt This Issue is about internal events only? Yes. Should we leave it open. The intention that these were non-interrupting. Interrupting would interfere with normal completion. Similar to use of conditional events. Should we adjust based on that? No strong reason to disallow, interrupting events. Should we simplify the Multi-Instance activity, based on using conditional events? Action: Hagen will contact Oliver from SAP and may generate issue on simplifying Multi-Instance activity based using conditional events. Is there any formal meaning for Exception flow? Probably more was described in v1.2 The proposal would be to Close with no change. Don't have a use case, but don't see a reason to restrict. |
| Comment by Stephen White [ 01/Dec/09 09:34 PM ] |
| There is a description of Exception Flow in Table 7.2 on page 27 (57 of pdf). |
| Comment by Stephen White [ 22/Mar/10 01:49 PM ] |
| proposalScheduledForBallot11 |
| Comment by Hagen Volzer [ 24/Mar/10 11:11 AM ] |
|
##New Proposed Resolution: Close without change
See comments above. |
| Comment by Hagen Volzer [ 26/Mar/10 08:50 AM ] |
| Reason for proposal: The design of the MI activity was done with the use case in mind that the catching boundary event is non-interrupting. However, we do not see a strong reason to rule out that the catching boundary event could be interrupting. Therefore, we propose to close without change. |
[BPMNFTF-286] [OMG 14537] businessRuleTask element in the BPMN 2.0 schema file
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 8 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Tammo van Lessen |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMNFTF-286-process-activities-v2.doc
BPMNFTF-286-process-activities.doc
BPMNFTF-286-Semantic.xsd
BPMNFTF-286-Semantic.xsd.diff
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: sect. 10.2.3, Table 10-11, FormalNumber: BPMN 2.0 schema Version: v 0.9.14 RevisionDate: may 22 Page: p175 Title: businessRuleTask element in the BPMN 2.0 schema file is missing the implementation attribute Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: businessRuleTask Element (Semantic.xsd vs. v0.9.14, sect. 10.2.3, Table 10-11, p175) The businessRuleTask element in the BPMN 2.0 schema file Semantic.xsd is missing the implementation attribute of type BusinessRuleTaskImplementation as per the specification documentation. -----Proposal---------------- 03/01/2010 ------------------------- ##Proposed Resolution: Fixed All implementation attributes are changed to string fields. Valid attributes are "##WebService" for the Web service technology, "##unspecified" to leave the implementation technology open or any other URI for any technology or coordination protocol. As an example WS-HumanTask is mentioned as such a technology in User Tasks. Tables and figures need to be updated according to the comments in the attachment. The attached XSD and the diff is still valid. It introduces a new complex type tImplementation, accepting anyURI, ##WebService or ##unspecified. |
| Comments |
| Comment by Stephen White [ 18/Nov/09 03:33 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-18 ----------
We will need a minor update to the schema and the XML snippet in the spec. The issue was assigned to Suzette |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:31 PM ] |
|
Actually, I would like to understand the value of this attribute.
There are other similar implementation attributes on other task types, and they generally cause confusion. They were kept for backwards compatibility. But given that the BusinessRuleTask is new to BPMN 2.0, what is the value (and use-case) for having an implementation attribute? What do these enumeration values mean (they're not defined anywhere)? |
| Comment by Stephen White [ 30/Nov/09 07:20 PM ] |
|
---------- Discussion during BPMN FTF Call on 2009-11-30 ----------
This is for calling a business rule engine. Implementation attribute The schema does not have the attribute This has a similar structure as user task. We will discuss on next process orchestration meeting. This week. |
| Comment by Suzette Samoojh (IBM) [ 01/Dec/09 04:49 PM ] |
|
Yes, I understand that the schema does not have this attribute.
But neither does the UML model, the XMI format, or Figure 10.10. The only place this attribute appears is in table 10.11. So another way of looking at it is there is an attribute in table 10.11 which does not appear anywhere else. And a possible counter-proposal would be to remove the attribute from that table. I'm not proposing this yet ... I am merely trying to understand the use-case for this attribute and the value of having it. Similar attributes on other legacy task types tend to cause confusion. So are we doing this to repeat a pre-existing (possibly confusing) pattern, or are we doing this because there is an actual need and use-case for this attribute. |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:25 PM ] |
|
Proposal: Remove the implementation attribute from the spec table 10.11. No changes needed to the XSD or metamodel.
If we later identify a concrete use-case, at that point we can add it back in. |
| Comment by Stephen White [ 03/Feb/10 05:14 PM ] |
|
-------------------- Discussion during Converence call on 2010-02-03 -----------------------
Business Rule Task -- Implementation attibute What is the value of this attribute? Not in figure 10.10. Not in schema What does the implementation attribute do? Does it make sense for Business Rule Task? or any of the Tasks? Just for consistency? Could implement as a Web service But not documented as to how to do this? Should be at Task level? There is no explanation as to what the attribute or enumeration means? Just remove the BusinessRuleWebService enumeration? User Task has a HumanTaskWebService. There is a known coordination protocol for User Task, but not for Business Rule Task. There is not spec description on either. We need to raise an issue on the User Task? Make the attribute more extensible? Make all implementation attributes URI instead of enumeration? Action: Tammo will generate proposal for all implementation attibutes |
| Comment by Tammo van Lessen [ 04/Feb/10 01:46 PM ] |
| Schema changes. |
| Comment by Tammo van Lessen [ 04/Feb/10 01:47 PM ] |
| Proposed fix attached. (word file with change tracking) |
| Comment by Tammo van Lessen [ 04/Feb/10 02:10 PM ] |
|
-------------------- Proposal ----------- 2010-02-04 ---------------------------------
##Proposed Resolution: Fixed Implementation attributes are supposed to identify technologies and/or potentially used coordination protocols like WSHT, WS-Coordination,... Thus, is seems better to introduce an extensible attribute instead of using a fixed enumeration because the spec should be technology agnostic. The proposed fix is to make all implementation attributes of type anyURI. Backward compatibility is maintained by introducing standard URIs for "Unspecified" and "WebService". "Other" is not needed anymore because a technology is either unspecified or directly identified by an URI. WSHT can be used as an example in case its standardization process is completed before. Otherwise we can add another internal URI substituting "HumanTaskWebService". The attached word file contains the proposed changes. There are three things that could be discussed: a) instead of using full URIs for "unspecified" or "WebService" (like http://schema.omg.org/spec/BPMN/2.0/taskImplementation#unspecified) I thought the XSD-like approach to use "##WebService" and "##unspecified" might be easier to understand. b) How to deal with WSHT and "HumanTaskWebService"? Currently User Tasks support the implementation value "HumanTaskWebService" but nowhere is explained what it actually means. That's why I decided to drop it in favor of a full qualified URI to WSHT. However, even for this case, there is no standardized URI for this or other technologies, so we should discuss whether we want to maintain a list/mapping of URIs to technologies or not. I believe it shouldn't be part of the spec and thus added just an example. But at some point in time, vendors need to agree on URIs for that attribute. c) Only the User Task mentions explicitly the implementation attribute, all others just have it in the table. Should we copy this sentence to the other tasks (Business Rule Task, Service Task, Send Task, Receive Task) as well? |
| Comment by Stephen White [ 11/Feb/10 12:31 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
A proposal was generated based on our previous discussion. Change implementation to any URI How to add existing technologies? How to specify that any other technology String? or any URI for MM The proposal will be updated Optional att of URI of a concrete protocol, probably of type string assumption is Web service Discuss on Monday call |
| Comment by Tammo van Lessen [ 12/Feb/10 03:24 PM ] |
| Revised proposal attached. |
| Comment by Tammo van Lessen [ 12/Feb/10 03:34 PM ] |
|
All implementation attributes are changed to string fields. Valid attributes are "##WebService" for the Web service technology, "##unspecified" to leave the implementation technology open or any other URI for any technology or coordination protocol. As an example WS-HumanTask is mentioned as such a technology in User Tasks. Tables and figures need to be updated according to the comments in the attachment. The attached XSD and the diff is still valid. It introduces a new complex type tImplementation, accepting anyURI, ##WebService or ##unspecified. |
| Comment by Ivana Trickovic [ 15/Feb/10 06:13 AM ] |
|
------------- New Proposed Resolution ----- 2010-02-15 -------------
See the comment above. |
| Comment by Tammo van Lessen [ 17/May/10 07:50 PM ] |
|
Spec-Draft3-review
page 210, Table 10.16: The XML snippet is not correct. "timplementation" should read "tImplementation" and the type tUserTaskImplementation" does not exist anymore. It is now "tImplementation" and defined as described below. The whole snippet should read as follows (copy-pasted from draft3's Semantic.xsd): <xsd:element name="userTask" type="tUserTask" substitutionGroup="flowElement"/> <xsd:complexType name="tUserTask"> <xsd:complexContent> <xsd:extension base="tTask"> <xsd:sequence> <xsd:element ref="rendering" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="implementation" type="tImplementation" default="##unspecified"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="rendering" type="tRendering"/> <xsd:complexType name="tRendering"> <xsd:complexContent> <xsd:extension base="tBaseElement"/> </xsd:complexContent> </xsd:complexType> <xsd:simpleType name="tImplementation"> <xsd:union memberTypes="xsd:anyURI"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="##unspecified" /> <xsd:enumeration value="##WebService" /> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType> |
| Comment by Stephen White [ 18/May/10 04:02 PM ] |
| Done |
[BPMNFTF-285] [OMG 14535] Method of specifying a default SequenceFlow is awkward
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Chagford CC (Frank Millman frank@chagford.com)
Specification: BPMN2.0 Section: 10.5 FormalNumber: bmi/2009-05-03 Version: v0.9.14 RevisionDate: 05/22/2009 Page: 300 Title: Method of specifying a default SequenceFlow is awkward Nature: Clarification Severity: Minor Description: I have looked at a few sample BPMN2.0 xml instances, such as those in the draft spec, those in the book 'BPMN Method and Style', and others found on the web. In all cases, SequenceFlow elements are shown with a sourceRef and a targetRef, but no id. This seems reasonable. However, I have now discovered that, to specify a 'default' SequenceFlow for an Inclusive or Exclusive Gateway, you must populate the 'default' attribute of the Gateway with a reference to the SequenceFlow. As I understand it, this reference must refer to the id of the SequenceFlow. This seems unnecessarily complicated. To me, the obvious way of specifying a default SequenceFlow is to have a boolean attribute on the SequenceFlow itself, defaulting to false. If there is a good reason to specify it as a reference on the Gateway, I would have thought it would be good practice to always assign an id to a SequenceFlow. Otherwise, to make one of them a default, you have to, first, assign an id to it, and then use the id as a reference on the Gateway. This seems awkward. -------------------- Proposal ----------- 2009-11-18 --------------------------------- ##Proposed Resolution: Closed; No Change The current solution might be confusing if someone was building a BPMN model directly with XML, but we don't expect that to happen much. The current definition is simpler for tools to implement default Sequence Flow and the end user should not be impacted. By putting the default attribute in the activity and gateway, we ensure in a simple way that there is only one default sequence flow. If the attribute should be part of the sequence flow elements, tools would need to validate that only one of the outgoing sequence flows have the attribute set to true. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 18/Nov/09 03:31 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-18 ----------
After discussing this issue, we agreed that there was no need to change the spec or schema. The current solution might be confusing if someone was building a BPMN model directly with XML, but we don't expect that to happen much. The current definition is simpler for tools to implement default Sequence Flow and the end user should not be impacted. Mariano will provide the proposal to close; no change, with the explanation. |
| Comment by Suzette Samoojh (IBM) [ 23/Nov/09 10:09 AM ] |
| Also, "default" is contextual ... it only means something within the context of the activity or gateway that is designating the default (i.e. this is the default sequence flow for this activity). It also is the most efficient means of enforcing correctness (i.e. that a particular activity does not have multiple defaults). |
| Comment by Mariano Benitez (Oracle) [ 16/Dec/09 03:11 PM ] |
|
-----Proposal-on-2009---
Testing, please disregard. |
[BPMNFTF-284] [OMG 14446] Lane.partitionElementRef incorrectly defined
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: IBM (Suzette Samoojh ssamoojh@ca.ibm.com)
Specification: BPMN 2.0 Section: 10.7 FormalNumber: BPMN Version: 2.0 RevisionDate: 05/22/2009 Page: 316 Title: Lane.partitionElementRef incorrectly defined Nature: Revision Severity: Significant Description: Consider swim lanes representing performers. - The spec states that the Lane.partitionElementRef would reference a Performer. This won't work since Performers are owned by Activities. Hence would result in a different Lane for every Activity.Instead the Lane.partitionElementRef should instead reference a Resource, which multiple Performers may reference. - The XSD defines Lane.partitionElementRef as an IDREF. It should instead be a QName, to allow references to a Resource in a different Definitions file. -------------------- Proposal ----------- 2009-11-27 --------------------------------- ##Proposed Resolution: Fixed (a) On spec pg 285, replace "e.g., all Lanes in a LaneSet defines the Performer element as the partition element, but all with different values" with "e.g., all Lanes in a LaneSet reference a Resource as the partition element, but each Lane references a different Resource instance". (b) Update the tLane type in the XSD, replacing <xsd:attribute name="partitionElementRef" type="xsd:IDREF"/> with <xsd:attribute name="partitionElementRef" type="xsd:QName"/> to allow for Resources in a different definitions file. (c) The XSD snippet in the spec will also need to be similarly updated. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 18/Nov/09 03:27 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-18 ----------
We discussed the relationship between re-usable resources and activityResources, such as Performer. Everything seemed ok. The metamodel seems to allow any attribute to be used for Lanes. The issue description is correct that the Activity Performer should not be used since each Activity owns it's own Performer (and thus there would be a separate Lane for each Activity). Root Resources should be used. Other elements can also be used. We need to be able to support situations such as the SoaML example, which is currently using Conversations for the Lanes. Another issue is asking for a Lanes example. We agreed that the schema should use QName instead of IDREF. The text may also need updating if there is some confusing statements (besides the lack of an example). Perhaps Suzette can provide a proposal. |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:50 PM ] |
|
Proposal
1. On spec pg 285, replace "e.g., all Lanes in a LaneSet defines the Performer element as the partition element, but all with different values" with "e.g., all Lanes in a LaneSet reference a Resource as the partition element, but each Lane references a different Resource instance". 2. Update the tLane type in the XSD, replacing <xsd:attribute name="partitionElementRef" type="xsd:IDREF"/> with <xsd:attribute name="partitionElementRef" type="xsd:QName"/> to allow for Resources in a different definitions file. The XSD snippet in the spec will also need to be similarly updated. The Lanes example should also include an example using Resources, since this is the most common usage of Lanes. |
| Comment by Ivana Trickovic [ 03/May/10 08:41 AM ] |
|
Beta 1. Draft 2.
XSD not properly updated (the semantic.xsd). The spec changes look ok. |
| Comment by Suzette Samoojh (IBM) [ 03/May/10 03:46 PM ] |
| Thanks. Addressed in the latest version of the XSD (to be published with Draft 3). |
[BPMNFTF-283] [OMG 14441] Semantic.xsd v0.9.14, sect. 8.2.1, p76-77 baseElement
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
******************************************************************************* Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 8.2.1 FormalNumber: BPMN 2.0 schema Version: v0.9.14, RevisionDate: may 22 Page: 76-77 Title: Semantic.xsd v0.9.14, sect. 8.2.1, p76-77 Nature: Clarification Severity: Critical test: 3qw8 B1: Report Issue Description: In the Semantic.xsd schema, the baseElement has its Id attribute as optional. This has the effect by inheritance that all elements have optional Ids. Although Figure 8-5 and Table 8-5 does not speficy this attribute as required, I believe it should be??? -------------------- Proposal ----------- 2009-11-27 --------------------------------- ##Proposed Resolution: Fixed - Update the description of the id attribute (table 8.5, spec pg 46) to add "The id is required if this element is referenced or intended to be referenced by something else. If the element is not currently referenced and is never intended to be referenced, the id may be omitted." ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:27 PM ] |
|
The id attribute was deliberately made optional.
The id of an element is only necessary for interchange when that element is referenced. There are many BPMN elements that are never referenced by other elements. And so, lack of an id does not break interchange. Hence it is optional for those elements. Many tools will likely choose to assign ids to all elements for their own internal use. Hence we wanted to support ids on all elements. But they are not strictly required on all elements. Also note that if an element is intended to be referenced, an id should be assigned (in case it needs to be referenced at a later time). Proposed update to the spec, for additional clarification. - Update the description of the id attribute (table 8.5, spec pg 46) to add The id is required if this element is referenced or intended to be referenced by something else. If the element is not currently referenced and is never intended to be referenced, the id may be omitted. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-282] [OMG 14433] The schema for expression and formalExpression does not lead to the intended capability of substituting and natural language expression by a formalExpression
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Section: Sematic.xsd vs. v0.9.14, sect. 8.3.7, pp106-107 FormalNumber: BPMN 2.0 schema Version: v 0.9.14 RevisionDate: may 22 Page: 106-107 Title: The schema for expression and formalExpression does not lead to the intended capability of substituting and natural language expression by a formalExpression Nature: Revision Severity: Significant >Description: In the schema, the substitutionGroup relation is place between the expression element and the formalExpression element, not the types. Thus elements of type expression do not benefit from the substitutionGroup. (e.g. activationCondition in the complexGateway is of type tExpression and thus cannot accept a formalExpresion). ##Proposed Resolution: Closed, No Change The FTF does not see a problem with the current state of the specification. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 27/Oct/09 02:38 PM ] |
|
Comment/further description for In the Semantic.xsd, the element formalExpression of type tFormalExpression has a substitutionGroup for expression (with the intention that one can substitute a string description of the expression by a formal language expression) All is fine there. Now in the complexeGatway Element, there is an attribute called activationCondition which is of type tExpression. I believe that the intention was for activationCondition to be either a string description of the expression or a formal language expression, But the activationCondition is of type tExpression and thus will not accept a formal expression of type tFormalExpression. (and thus not providing the intended substation mechanism) see attached example file substitution_error.xml The same problem also arise for: • loopCondition in the standardLoopCharacteristic is of type tExpression • loopCardinality in the multiInstanceLoopCharacteristics is of type tExpression I believe these two have the same problem of not being able a formalExpression for the same reasons. |
| Comment by Stephen White [ 18/Nov/09 03:23 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-18 ----------
We didn't really understand the issue. Suzette might have more insight. |
| Comment by Suzette Samoojh (IBM) [ 26/Nov/09 06:28 PM ] |
|
It is true that these elements don't make full use of substitution groups.
However it is not true that you can't use a formalExpression for them. The way to do so is slight more verbose, but it is possible. To illustrate the issue, consider the following examples. Pattern 1: Uses ref="expression" <xsd:complexType name="tResourceAssignmentExpression"> ... <xsd:element ref="expression" minOccurs="1" maxOccurs="1"/> ... </xsd:complexType> Pattern 2: Uses type="tExpression" <xsd:complexType name="tConditionalEventDefinition"> ... <xsd:element name="condition" type="tExpression"/> ... </xsd:complexType> This issue is complaining about Pattern 2. An XML instance of Pattern 1, with a formal expression <resourceAssignmentExpression> <formalExpression language="someLanguage" evaluatesToTypeRef="abc">expression body</formalExpression> </resourceAssignmentExpression> An XML instance of Pattern 2, with a formal expression <conditionalEventDefinition> <condition xsi:type="tFormalExpression" language="someLanguage" evaluatesToTypeRef="abc">expression body</condition> </conditionalEventDefinition> In Pattern 2, the xsi:type="tFormalExpression" enables formal expressions. Hence it is not true that these elements cannot accept a formal expression. ---------------------------------------------------------------------------- Options to address this issue: 1. Do nothing. FormalExpressions can be used for these elements. There is no breakage in capability. 2. Wherever we use Pattern 2 (and there are many places), change them to use Pattern 1. Implication 1: We cannot use descriptive names (e.g. "loopCondition") for these elements. Implication 2: We cannot apply Pattern 1 to constructs that have multiple expressions (e.g. tMultiInstanceLoopCharacteristics). These constructs must continue to use Pattern 2. 3. Introduce new root level elements for each case where we use Pattern 2. For example, add root-level elements like: <xsd:element name="loopCondition" type="tFormalExpression" substitutionGroup="expression"/> <xsd:element name="loopCardinality" type="tFormalExpression" substitutionGroup="expression"/> They would have to be of type tFormalExpression. If not, then XML instances would still have to use the xsi:type="tFormalExpression". Vendor-specific expression extensions would have to be extensions of tFormalExpression. Vendors can't extend simply from tExpression. This option has to be ruled out IMO, for the reasons given above. My preference is 1-Do nothing. Option 2 will partially solve the issue (in the cases where we have constructs with a single expression), but it does so at the expense of readability and descriptive element names. |
| Comment by Suzette Samoojh (IBM) [ 02/Feb/10 06:28 PM ] |
|
Proposal: Close with no change.
See detailed write-up (option 1) in prior comment. |
| Comment by Denis Gagne [ 15/Feb/10 08:37 AM ] |
|
Given that we provide a schema and that xml manipulation will be common place, I would thus prefer your option 2 (comment in the Jira).
I understand the implications (and implication 2 could be detoured with a wrapper element). Grant you this will not be as OO elegant but I believe it will make schema usage somewhat more intuitive and somewhat more xslt friendly. The xsi:type construct is a somewhat controversial way of doing polymorphism in a language that is supposed to be structured rather than OO. |
| Comment by Suzette Samoojh (IBM) [ 16/Feb/10 10:08 AM ] |
|
I included Option 2 for completeness. But I don't recommend Option 2.
Reason being, Option 2 has severe implications on readability and intuitiveness of the specification. Going this route does not just impact the XSD. The names we apply to the XSD would also propagate to the UML metamodel and the spec. So the implication is that the spec itself cannot use descriptive and meaningful names like "loopCondition". Given that the spec is really the primary means of communicating the concepts behind BPMN, readability of the spec to human beings should be paramount. I don't share your concerns around xsi:type. I see it used all the time. And it is heavily used within XMI (the OMG standard), and within the current BPMN XMI format (irregardless of this change). Hence I don't see this as a strong enough reason to reduce readability of the specification. Denis, if you have other proposals or variations to the above proposals (such as your mention of a 'wrapper element'), please post the details. Maybe they will address my concerns (?). Otherwise, I default back to my prior response: the problem statement that the XSD cannot accommodate tFormalExpression in places like activationCondition or loopCondition is not true. It accommodates it via the use of xsi:type. |
| Comment by Stephen White [ 17/Feb/10 06:16 PM ] |
| New Proposed Resolution |
[BPMNFTF-281] [OMG 14432] text attribute is missing from the Documentation
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Name: Denis Gagne Company: Trisotech mailFrom: dgagne@trisotech.com Notification: Yes Specification: Denis Gagne Section: 8.2.2 FormalNumber: BPMN 2.0 schema Version: v 0.9.14 RevisionDate: may 22 Page: 77 Title: text attribute is missing from the Documentation element of the v 0.9.14 schema Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The text attribute is missing from the Documentation element of the v 0.9.14 Semantic.xsd schema. Thus no text description of a BPMN element can be captured by the provided schema -------------------- Proposal ----------- 2009-11-27 --------------------------------- ##Proposed Resolution: Fixed - Update the description of the text attribute in the specification text after Table 8.6 (spec pg 46) to add "In the BPMN schema, the tDocumentation complexType does not contain a text attribute or element. Instead the documentation text is expected to appear in the body of the documentation element. For example: <documentation>An example of how the documentation text is entered.</documentation> " ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:12 PM ] |
|
There is no need for an explicit text attribute. The nature of XSD allows the body of the element to hold the documentation text.
For example: <documentation>An example of how the documentation text is entered.</documentation> Proposed addition to the spec, to add extra clarification. This addition would be made to Section 16.2 Documentation The tDocumentation complexType does not contain a text attribute or element. Instead the documentation text is expected to appear in the body of the documentation element. <documentation>An example of how the documentation text is entered.</documentation> |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
| Comment by Ivana Trickovic [ 11/Jun/10 10:56 AM ] |
|
spec-May24-review
[AB feedback] Feedback from Steve Cook, Microsoft: Resolution 14432 specifies a bunch of changes to 8.3 which seem unrelated to the issue: there seems to be a mistake here. Please clarify. |
| Comment by Ivana Trickovic [ 11/Jun/10 10:57 AM ] |
|
As per the 6/7 meeting:
- The referred changes are related to issue 14423 - Add in the response that additional changes to the convenience document need to be made (see comment added to |
[BPMNFTF-280] [OMG 14423] XSD Schemas for transfer of Model instances of DI and DD Metamodels
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Robert Shapiro |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
BPMN DI Schema Baseline Feb 19.zip
BPMNDI Ballot Proposal.zip
BPMNDI Ballot Proposal.zip
Changes to Internal Draft 3.docx
Changes to Internal Draft 3.docx
Revised BPMNDI Ballot Proposal Apr 23.zip
Revised BPMNDI Ballot Proposal Apr 26.zip
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
Location: BPMN 2.0 Beta 1 Annex B Summary of Issue: In the current BPMN 2 spec, Model instances of the BPMN2 Metamodel have two alternate forms for transfer: - XMI derived directly from the BPMN 2 Metamodel - Instances of the BPMN XSD schemas defined in BPMN 2 spec. The current Annex B of the Beta 1 BPMN 2 spec defines metamodels for DiagramInterchange (DI) and Diagram Definition (DD). However there are no BPMN XSD schemas defined for the DI and DD metamodels. Thus, it seems that XMI derived from these DI and DD metamodels currently the only normative way defined to transfer Model instances of these metamodels? The current plan is that this Annex B will be replaced with a reference to the adopted DI spec. Resolving issue involves the FTF answering two questions: 1) Is there a need to define "custom" XSD schemas, not based on XMI, as an alternative for transfer of DI and DD model instances. 2) If the answer to question 1 is yes, will these "custom" XSD schemas be defined by the BPMN 2 FTF, or the DI submitters? ##Proposed Resolution: Fixed These changes are required: 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 Chapter 13 is to be replaced with the provided Chapter 13 in attached ZIP Annex B is to be replaced with the provided Annex B in attached ZIP BPMN DI schemas are to be replaced with the schemas provded in attached ZIP All files are included in the following zip file: http://www.osoa.org/jira/secure/attachment/10740/Revised+BPMNDI+Ballot+Proposal+Apr+26.zip Note on 2010-04-26: The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be: - http://www.omg.org/spec/BPMN/20100524/MODEL for the semantic model XML Schema - http://www.omg.org/spec/BPMN/20100524/MODEL-XMI for the semantic model XMI - http://www.omg.org/spec/BPMN/20100524/DI for diagram interchange XML Schema - http://www.omg.org/spec/BPMN/20100524/DI-XMI for diagram interchange XMI xsds For Diagram Definition, the version we are including in the appendix will be: - http://www.omg.org/spec/DD/20100524/DC - http://www.omg.org/spec/DD/20100524/DI - http://www.omg.org/spec/DD/20100524/DC-XMI - http://www.omg.org/spec/DD/20100524/DI-XMI |
| Comments |
| Comment by Ivana Trickovic [ 07/Oct/09 04:44 AM ] |
|
Deliverables agreed during the 10/5 FTF meeting:
- New meta-model classes for BPMN domain specific DI/DD as subclass of generic DI/DD submission. - Generated XMI from this meta model - BPMN Specific XSDs for diagram interchanges |
| Comment by Mariano Benitez (Oracle) [ 09/Dec/09 04:56 PM ] |
|
--------------- Discussion during F2F/Call on 2009-12-09 ----------------------------------
I tried to gather 2 things, use cases and considerations on each of the options we have. Please comment on any of these elements. We expect that we put here all the use cases anyone thinks if worth supporting and agree on wich ones are we decide to support. This will narrow the possibilities. + use cases we would be agree on supporting in the spec. A) - Edition of processes for execution - A process developer adding removing process elements, in full comformance mode. - The developer would update both the visual and the semantic models. B) - Rendering of a process diagram - A visualization tool would pick up an exported diagram and display it. It is not defined if the exported model would include the semantic model or not. a) use both visual and semantic models b) use just the visual model c) use a generated image based on the visual and semantic models - no changes to models C) - Edition of a diagram - Some very simple edition of the visual model, just for clarity of the diagram. - this would be ok just as is, but probably that modified visual model would go back to the repository so it is later used. - this would probably use one of the simple conformance levels, even if the process is fully described (with full semantics) + Considerations on the possible options 1) visual model can exist independent of a semantic model a) we need to duplicate the information from the semantic model into the visual model a.1) this could be ok when this only applies to the interchange of visual models a.2) tools would only copy the information from the semantic to the visual model when exporting the models a.3) the metamodel should support both a "connected" and a "disconnected" mode for a visual diagram b) exports contain only the visual information, hiding the technical/private details of the activities (which in some cases would be required) c) it creates additional complexity for the spec and tools to figure out where to take the information from c.1) how do we resolve the case when there is a semantic model and there is also information in the visual model? what if a name is attached to an activity node, but the real activity has a different name? d) some tools will only understand the visual model d.1) what if such a tool receive a visual model with an attached semantic process model? - they would fail opening it? - they would need to understand the semantic model anyway to extract the required information e) by having a "disconnected" visual model (a visual model without a semantic model), customers would likely require that we "connect" an existing visual model to an existing semantic model, which seems to be a very complex operation 2) visual model always require the semantic model a) tools could generate a simpler semantic model with just the content required for rendering the diagram a.1) this would provide a similar functionality as 1.b), but it would require work on tools to generate the simple process model b) full export is no different from an export for visualization, tools would create a simpler model when the export for visualization. c) since all tools would understand the semantic model, a user could decide to export the entire semantic model or just the things required for visual display d) it requires that visualization tools to parse the semantic model, besides the visual model. d.1) this is already the case in XPDL d.2) it is probably no big deal since they must understand only a little piece of it Regards, MAriano |
| Comment by Mariano Benitez (Oracle) [ 10/Dec/09 09:05 AM ] |
|
Comments via email from Bruce Silver on Dec 9th.
1. When you say visual model "independent" of semantic model, not clear whether you mean (a) visual model has meaning in absence of a semantic model, or (b) visual model may have coexist with semantic model but could have values in conflict with corresponding semantic elements. 2. Similarly, the case of visual model requiring semantic model has two cases as well: (a) no duplication of elements (hence no potential for conflict); or (b) duplication of elements in semantic and visual models, hence potential for conflict. In both cases, (b) is not only too verbose but presents all the conflict resolution issues. 1(a) would seem to have nothing to do with BPMN per se. I don't see why OMG would get involved in it. 2(a) makes the most sense to me. From your exposition, I would say it makes the most sense to you as well. |
| Comment by Mariano Benitez (Oracle) [ 10/Dec/09 09:12 AM ] |
|
Now my comments on Bruce's comments:
The understanding is that the visual elements will contain either a) only the information that is NOT present in the semantic model (position, size, etc) b) ALL the information required for rendering (including labels, types, position, size, etc) (this is what we are discussing) Having described the use cases I conclude it makes more sense to do a) since it does not create any possible conflict (no redundant information) and for the lightweight cases (visualization) it would not be too hard to parse the semantic model and extract the required info. The plan would be that anyone interested would describe their use cases, see how they would be solved by either option, and then if there is still no consensus, we vote. |
| Comment by Suzette Samoojh (IBM) [ 10/Dec/09 03:32 PM ] |
|
I agree with a) - the visual model should only contain information that is neither present nor derivable from the semantic model.
Redundancy creates more problems than it appears to solve, and it's not clear there is a strong case (at the moment) for the alternative. |
| Comment by Reiner Hille-Doering [ 18/Dec/09 08:18 AM ] |
|
Generally I'm a fan of redundancy-free DI models, so e.g. I fully agree not to store the activity names in the DI model.
Hoever, I have the feeling that it could be good to TYPE of the linked semantic object. This could be a very generic association in the root class of the DI MM. Additionally having the untyped reference to the semantic element having an association to CMOF::Class. This allows for the case that the link to the semantic object becomes dangling for some reason to at least know what kind of object it was. It e.g. allows the diagram tool to choose the right shape for rendering, e.g. Event, Activity, Gateway and so forth. |
| Comment by Denis Gagne [ 19/Feb/10 01:49 PM ] |
|
We have a BPMN DI xsd Baseline Proposal. (supporting files to be attached to this issue)
This schema is completely aligned with the DI MM. (With Maged, we are putting the last touch to have the schema actually generated from the MM) Some choices were made in preparing this Baseline that need to confirmed or infirmed. These choices will be presented as issues linking to this proposal as to allow everyone to comment. |
| Comment by Denis Gagne [ 19/Feb/10 01:54 PM ] |
|
This zip includes the BPMN DI and associated schemas.
Also included is a PDF report of the latest DI MM. |
| Comment by Ivana Trickovic [ 22/Mar/10 03:12 AM ] |
| proposalScheduledForBallot11 |
| Comment by Denis Gagne [ 12/Apr/10 03:09 PM ] |
|
The changes bellow will have also to be included as part of the proposal for DI (from 560):
8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 |
| Comment by Denis Gagne [ 15/Apr/10 02:23 PM ] |
|
##Proposed Resolution: Fixed
These changes are required: 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 Chapter 13 is to be replaced with the provided Chapter 13 in attached ZIP BPMNDI Ballot Proposal Annex B is to be replaced with the provided Annex B in attached ZIP BPMNDI Ballot Proposal BPMN DI schemas are to be replaced with the schemas proovded in attached ZIP BPMNDI Ballot Proposal |
| Comment by Tom Rutt [ 19/Apr/10 04:26 PM ] |
|
Fine work, howeverI have a couple of questions for clarification
The stuff Denis distributed has three xsd files bpmndi.xsd dc.xsd di.xsd Question 1) Are these for the "schema version" of interchange only? In particular, are there also cmof files for the DI stuff from the DI submission which will be part of the package that the bpmn 2 ftf delivers as part of our ftf output? Are there cmof files for the bpmndi stuff for the metamodel in our finalization output? Remember, there is a requirement to have both XMI and "custom XSD" ways to interchange bpmn diagram data. The FTF needs to clarify this before completion. Question 2) I have a concern about the namespace URLs being proposed. (Pete Rivett has raised a similar concern on Issue 456) I note that there is a dated uri for the di namespace, which is a good thing.. However the namespace for bpmndi.xsd is not dated, but has a bpmn version number. I wonder why the bpmndi.xsd does not use a dated namespace uri? That way if the next version has a compatible namespace change, we do not have to change the namepsace uri. see the smsc namespace policy document: http://www.omg.org/members/cgi-bin/doc?smsc/09-09-07.doc Tom Rutt |
| Comment by Tom Rutt [ 22/Apr/10 04:42 PM ] |
|
This proposal is not yet aligned with the smsc namespace policy http://www.omg.org/members/cgi-bin/doc?smsc/09-09-07.pdf
The BPMN version should not used in the namespace url, the date is used instead. This way future bpmn versions can extend the existing namepace, rather than requiring a new one for compatible changes. Also, the namespace for the xmi xsd should be different form the namespace for the bpmn specific xsd. So I propose we use the following namespace URI values > > DD spec > > > > Diagram Commons : http://www.omg.org/spec/DD/20100414/DC > > > > Diagram Interchange: http://www.omg.org/spec/DD/20100414/DI > > > > > > BPMN 2.0 DI > > http://www.omg.org/spec/BPMN/20100414/BPMNDI > > > > Thus the xmi xsds would be > > Here are my proposal for the namespaces aligned with the OMG naming convention: > > > > DD spec > > > > Diagram Commons : http://www.omg.org/spec/DD/20100414/DC-XMI > > > > Diagram Interchange: http://www.omg.org/spec/DD/20100414/DI-XMI > > > > > > BPMN 2.0 DI > > http://www.omg.org/spec/BPMN/20100414/BPMNDI-XMI > > |
| Comment by Denis Gagne [ 23/Apr/10 08:39 AM ] |
| Made some corrections and edits to Chapter 13 |
| Comment by Denis Gagne [ 26/Apr/10 12:52 PM ] |
| Changes to namespaces as per Apr 26 FTF Conf Call |
| Comment by Denis Gagne [ 13/May/10 04:40 PM ] |
|
Spec-Draft3-review
See file Changes to Internal Draft 3 attached for the changes needed to the BPMN DI chapter. Plus these changes were not applied from orginal proposal 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 |
| Comment by Denis Gagne [ 14/May/10 09:47 AM ] |
|
Spec-Draft3-review
See file Changes to Internal Draft 3 attached for the changes needed to the BPMN DI chapter. ***Use the latest version of the file. I had left out some things in the first one... sorry :-( ****** Plus these changes were not applied from orginal proposal 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 [ Show » ] Denis Gagne [13/May/10 04:40 PM] Spec-Draft3-review See file Changes to Internal Draft 3 attached for the changes needed to the BPMN DI chapter. Plus these changes were not applied from orginal proposal 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 |
| Comment by Denis Gagne [ 17/May/10 02:50 PM ] |
|
Spec-Draft3-review
Here are my issues with the "visual edits": Section 12.2.3 : a series of quotation marks (") were introduced in front of text in each bullets for Sub sections Abstract Syntax, Generalizations, Attributes, and Associations. These quotation marks need to be removed. Table 12.8 Loop marker and sub-process marker have been inverted. + should be to the right (see original) Figure 12.7 Markers have been inverted (see original) Table 12.17 Event Sub Process border should be dotted not dashed. All depictions in this table. Table 12.17 Interrupting - Compensation - Event Sub-Process - Collapsed : there should not be a Compensation marker on the bottom. Table 12.18 Event Sub Process border should be dotted not dashed. Table 12.22 Label of DataStore should be under the shape Table 12.23: Interrupting Message Start Event is missing the envelop marker Table 12.23: Non-Interrupting Parallel Multiple Start Event: wrong marker used should be a plus marker Table 12.24: Bad Aliasing on gateways depictions Table 12.18 : Choreography Task and Choreography Task -Loop missing bottom border line of shape Table 12.28: Bottom border of shape missing for Choreography Task Shape and Choreography Task - Loop Shape(On screen, May not be the case on printed version) Table 12.29 : Sub-Choreography - Loop - Collapsed: Makers inverted. The + should be to the right of the loop marker. Table 12.29: Sub-Choreography - Sequential Multi Instance - Collapsed. Makers inverted The + should be to the right of the loop marker Table 12.29: Sub-Choreography - Parallel Multi Instance - Collapsed. Makers inverted The + should be to the right of the loop marker Table 12.30 The bottom border of the shape is missing (On the screen may be ok in print?) Table 12.32: Call Choreography Activity calling a Choreography - Loop : Makers inverted. The + should be to the right of the loop marker Table 12.32 Call Choreography Activity calling a Choreography - Sequential Multi Instance : Makers inverted. The + should be to the right of the loop marker Table 12.32: Call Choreography Activity calling a Choreography - Parallel Multi Instance : Makers inverted. The + should be to the right of the loop marker Table 12.36: Directed Data Association: the content of the cell beside the depiction was removed. It should be: DataInputAssociation or DataOutputAssociation Figure 12.13: Both message flows should have their message decorators showing. See original. Section 12.4.4: The reference to the figure is incorrect (4.4.1) Should read See Figure 12.14 Figure 12.15: This is all wrong see original. Figure 12.15: Typo: Participant 1 in shapes CT 1 and CT 2. Figure 12.15: For CT 1Participant 1 should be non initiating and Participant 2 initiating Figure 12.15 : CT 1 should have message decorator showing for Participant 1 and Participant 2. Figure 12.15 : For CT 2 Participant 1 should be non initiating and Participant 2 initiating Figure 12.15: CT 2 should have message decorator showing on only Participant 2 Figure 12.15: Shape SC should have Participant 2 as a middle initiating at the bottom |
| Comment by Ivana Trickovic [ 17/May/10 03:21 PM ] |
|
As per the meeting of May 17th: Agreed that this needs to be fixed
Steve made all changes, but the original figures could not be included so Steve created them again. Denis to review the chapter |
| Comment by Denis Gagne [ 03/Jun/10 09:21 AM ] |
|
spec-May24-review
Resolution no applied froom above 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 [ Show » ] Denis Gagne [13/May/10 04:40 PM] Spec-Draft3-review See file Changes to Internal Draft 3 attached for the changes needed to the BPMN DI chapter. Plus these changes were not applied from orginal proposal 8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator" 8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process 8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message Flow" Remove Figure 8-30 page 116 8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator" Remove the paragraph between Figure 8-32 and Figure 8-33 Remove Figure 8-33 page 117 |
| Comment by Falko Menge [ 07/Jun/10 08:50 AM ] |
|
spec-May24-review
Shouldn't the 'Collapsed Interrupting Error Event Sub-Process' on page 397 (427 PDF) of http://www.omgwiki.org/bpmn2.0-ftf/lib/exe/fetch.php?id=public%3Areport&cache=cache&media=public:bpmn_2-0_dtc-2010-05-03_-_no_markup.pdf have an Error symbol instead of a Compensation symbol? |
| Comment by Stephen White [ 10/Jun/10 06:59 PM ] |
|
completed fix for spec-May24-review comments
Note that the last two items in the first comment were already fixed (e.g. Figure 8-33 [from Beta]) |
[BPMNFTF-279] [OMG 14422] Add a User Event
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Notation, Process Orchestration, Schema, Semantics |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Stephen White | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
*******************************************************************************
Name: Stephen White Company: IBM mailFrom: wstephe@us.ibm.com Notification: Yes Specification: BPMN 2.0 Section: 10.4 FormalNumber: 09-08-14 Version: Beta 1 RevisionDate: Aug 2009 Page: 209 Title: Add a User Event Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN. ##Proposed Resolution: Defer Defer. The FTF agrees that this is an issue that should be resolved, but did not agree on a resolution and deferred its resolution to a future RTF. |
| Comments |
| Comment by Stephen White [ 11/Feb/10 12:24 PM ] |
|
-------------------- Discussion during Conference call on 2010-02-10 -----------------------
Out of scope for FTF? The is User doing something as opposed to another mechanism. The modeler wants to make this clear. More appropriate RTF? Should we Defer? We should elaborate the scenario. What are the notation and runtime, consequences? |
| Comment by Stephen White [ 16/Feb/10 10:49 AM ] |
|
-------------------- Proposal ------------- 2010-02-16 --------------------------------
Defer. The FTF agrees that this is an issue that should be resolved, but did not agree on a resolution and deferred its resolution to a future RTF. ------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 17/Feb/10 05:11 PM ] |
|
-------------- Discussed during Conference Call on 2010-02-17 ---------------------
The above proposal will be withdrawn. A new proposal for a specific resolution will be generated ----------------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 10/Mar/10 08:37 AM ] |
|
As per March F2F Meeting:
- This is a request for a new feature. - Close (out of scope) with no changes to the specification. |
| Comment by Stephen White [ 10/Mar/10 06:16 PM ] |
|
Being a request for a new feature does not automatically make it out of scope. As discussed on previous calls, small features like this are more appropriate for the FTF than RTFs. We need not wait for an RFP for this feature.
Besides, a proposal is nearly complete. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 12:59 PM ] |
|
##Proposed Resolution: Defer
The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
[BPMNFTF-278] [OMG 14363] Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar. While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X. -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14354 (JIRA BPMNFTF-270) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 26/Oct/09 03:03 AM ] |
| This is duplicate of BPMNFTF-270. |
| Comment by Ivana Trickovic [ 02/Nov/09 02:56 AM ] |
| Issue # 14363 is duplicate of issue # 14354. |
[BPMNFTF-277] [OMG 14362] Page 121, Figures 7.3 and 10-1 Redundant ways to model receiving messages
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Rutt | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14362 Page 121, Figures 7.3 and 10-1 Redundant ways to model receiving messages This is a style suggestion that will make diagrams clearer by removing redundant notations. There is a "receive event" to receive any kind of communication. For example, and event to receive a message. Or an event to receive a signal. Events are circles on the diagram. Additionally, BPMN allows a "receive type" activity, that is a rounded rectangle that receives messages. Receiving of a message seems more naturally to be an "event" and not an "activity" because an event is something that happens. An activity is something you do, and receiving something is really just waiting and not doing anything. So picturing receive an activity seems unnatural. The redundancy to two ways to draw this causes confusion. ------------------------ New Proposed Resolution ----------- 2010-01-27 ---------------------------- ##Proposed Resolution: Duplicate The proposal for 14353 (JIRA The spec could encourage the use of a "receive event", and to deprecate the "receive activity". Receive activity would still be allowed, but "deprecation" would put the standard on a path to eventually remove it, and would send a message to not use it or expect it to be there in the future. The figure 10-1 should be re-drawn to have receive message events instead of "receive activities". The doctor/patient example in figure 7-3 should be redrawn to use receive events instead of the receive activities. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 13/Nov/09 02:14 PM ] |
|
there is a big difference between send and receive tasks and events: tasks allow boundary events. In the case of receiving events you could solve it with an event based gateway, but for a throw event you cannot handle any other event (errors or other events). Also events allow different event definitions, while tasks only work with messages.
I do like the idea of deprecating these 2 tasks, but it requires a big effort to properly cover the use cases tasks support in the events. I would not do that in an FTF. So the proposal is to include a paragraph in section 10.4 Events (not sure where yet) to describe the valid use case for tasks, and put a design guideline to use events in favor of send and receive tasks. |
| Comment by Stephen White [ 27/Jan/10 10:10 AM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-27 ----------------------------
Close: Duplicate This issue is the same as Issue 14353 (JIRA 269) ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-276] [OMG 14361] Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Mr. Tom Rutt, tom@coastin.com)
This is issue # 14361 Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events There are activities that are only ended by events, thus the activity may have one or more events located on the border of the activity, but no "normal" non event exit of the activity. The request is that the spec include an explicit statement that the activity might have events on the border, but no other "natural" ending of the activity. If this is not agreed, the spec needs to explain how to model such activities. -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14352 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 29/Oct/09 03:07 PM ] |
| Looks like a duplicate of BPMNTFTF-268. |
| Comment by Ivana Trickovic [ 02/Nov/09 02:54 AM ] |
|
Closed as duplicate of |
| Comment by Ivana Trickovic [ 02/Nov/09 02:58 AM ] |
| Issue # 14361 is duplicate of issue # 14352. |
[BPMNFTF-275] [OMG 14360] Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion There are activities that are never ended - that is they have no natural completion, but are terminated only when the process itself is terminated. Monitoring activities are like that. If an activity is started, and there is never a conclusion of that activity, then this should be indicated by having no outbound arrow from the activity. This activity is concluded only by the termination of the process as a whole. For example, and process may have a main thread, but also split early and start a "monitoring" activity. This monitoring activity is designed to stay active until the process is concluded for some other reason. There is no way for the assignee of the activity to say "I am done monitoring this process" without the process itself being terminated. Since there is no "natural" end of the activity, there should be no arrow coming out of the activity node. I am not sure if this is a requirement of the spec, but there is a common perception that it is a requirement, that all activities have an outbound arrow coming out of it. This request is that the spec include a statement that it is explicitly OK to not have an arrow out of an activity that has no natural end to its execution. If this is not agreed, the spec needs to explain how to model such activities -------------------- Proposal ---------- 2009-12-11 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14351 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 26/Oct/09 03:00 AM ] |
|
This is duplicate of |
| Comment by Ivana Trickovic [ 02/Nov/09 02:59 AM ] |
| Issue # 14360 is duplicate of issue # 14351. |
[BPMNFTF-274] [OMG 14359] Page 22, Section 7.2.1 Associating Data Objects with process as a whole
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
Page 22, Section 7.2.1 Associating Data Objects with process as a whole Many workflow systems are designed around the concept that there is a process context that holds variables shared by all activities within that context. Since the swimming pool represents the process instance as a whole, there should be a way to associated process variables with the pool itself, which would be accessible by all activities within the pool. The spec should clarify how a model can associate data objects with the process as a whole. -------------------- Proposal ---------- 2009-12-11 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14350 (JIRA -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 26/Oct/09 02:56 AM ] |
|
This is duplicate of |
| Comment by Ivana Trickovic [ 02/Nov/09 03:01 AM ] |
| Issue # 14359 is duplicate of issue # 14350. |
[BPMNFTF-273] [OMG 14358] Page 29, Section 7.2.2 Fork and Join Differentiation
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Rutt | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14358 1. Page 29, Section 7.2.2 Fork and Join Differentiation BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence of parallel paths, and another AND gateway to end it. The behaviors of these two gateways are different, but they look the same. Suggestion is that the first AND gateway, that starts the parallel split have a thin line, while the gateway at the end which actually waits for multiple inputs will have a thick line. This corresponds to the thin and thick lines around start and end nodes. -------------------- Proposal ---------- 2009-11-13 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14349 (JIRA BPMNFTF-265) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Hagen Volzer [ 26/Oct/09 05:35 AM ] |
| BPMN allows the AND gateway to have multiple incoming and multiple outgoing sequence flow at the same time. How should those be drawn then? |
[BPMNFTF-270] [OMG 14354] Style suggestion to make diagrams clearer - XOR gateway
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is a style suggestion to make diagrams clearer This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar. While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X. |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:12 AM ] |
| I agree with this. Spec should indicate that empty diamond is preferred symbol for XOR gateway. |
| Comment by Hagen Volzer [ 26/Oct/09 05:43 AM ] |
| I think so too. |
| Comment by Mariano Benitez (Oracle) [ 27/Oct/09 02:34 PM ] |
| Me too. The most used artifact should be as simple as possible. |
| Comment by Stephen White [ 27/Oct/09 06:15 PM ] |
|
We discussed this during the 2009-10-26 FTF meeting.
The approach we came up with is to explain why there are two forms of the Gateway. In addition, if there are other places in the spec where there are multiple ways of doing things, we would explain why this is the case. The preferred choice of which method to use would not be stated in the spec. These are methodological decisions that are up to the modeler or tool. However, the spec will be consistent in using a method for general examples. Thus, we will state which method we will use. For example, most examples in the spec will show the exclusive gateway without the X. |
| Comment by Stephen White [ 22/Mar/10 05:50 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:33 PM ] |
| Update the issue resolution to clarify why FTF decided to defer the issue beyond just saying that the FTF was not able to allocate time. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 11:55 AM ] |
|
##Proposed Resolution: Defer
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. |
[BPMNFTF-269] [OMG 14353] Redundant ways to model receiving messages
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Notation, Process Orchestration, Semantics |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Rutt | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14353 Page 121, Figure 10-1 - Redundant ways to model receiving messages This is a style suggestion that will make diagrams clearer by removing redundant notations. There is a "receive event" to receive any kind of communication. For example, and event to receive a message. Or an event to receive a signal. Events are circles on the diagram. Additionally, BPMN allows a "receive type" activity, that is a rounded rectangle that receives messages. Receiving of a message seems more naturally to be an "event" and not an "activity" because an event is something that happens. An activity is something you do, and receiving something is really just waiting and not doing anything. So picturing receive an activity seems unnatural. The redundancy to two ways to draw this causes confusion. The spec could encourage the use of a "receive event", and to deprecate the "receive activity". Receive activity would still be allowed, but "deprecation" would put the standard on a path to eventually remove it, and would send a message to not use it or expect it to be there in the future. The figure 10-1 should be re-drawn to have receive message events instead of "receive activities". The doctor/patient example in figure 7-3 should be redrawn to use receive events instead of the receive activities. |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:25 AM ] |
|
Lombardi: Agree. Both send task and receive task appear to be redundant to me.
Also, in table 10-10 for operationRef: Operation it says "This attribute specifies the operation that is invoked by the Service Task." It should say "Receive Task". Similar comment for table 10-9 |
| Comment by Alex Moffat [ 15/Sep/09 08:57 AM ] |
|
Replacing the Receive Task with a message event is not that simple. If you had a receive task you could use a timer boundary event to recognize no response within a given time. To do that with an event you will have to use an event based decision gateway followed by a message event and a timer event.
Robert Shapiro Global360 |
| Comment by Alex Moffat [ 15/Sep/09 09:04 AM ] |
| Lombardi: If it is possible to use an event based decision gateway followed by a message event and a timer event then why have a Receive Task? Separate question as to whether the FTF can remove the Receive Task though. |
| Comment by Ivana Trickovic [ 09/Mar/10 11:10 PM ] |
|
As per March F2F Meeting:
- Both capabilities are in 1.1 and 1.2 so for it should be kept for backward compatibility - Also, receive activity is different from receive event as it may have other elements attached to it, e.g. boundary events - This is not a critical issue, so lower priority to major. - Proposal is to close (out of scope) with no changes to the specification. |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 01:13 PM ] |
|
##Proposed Resolution: Closed, Out Of Scope
This issue cannot be fixed in this FTF. |
[BPMNFTF-268] [OMG 14352] Modeling Activities that are only ended by Events
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration, Semantics |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Hagen Volzer |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14352 Page 26, Normal Flow row of Table 7.2 Modeling Activities that are only ended by Events There are activities that are only ended by events, thus the activity may have one or more events located on the border of the activity, but no "normal" non event exit of the activity. The request is that the spec include an explicit statement that the activity might have events on the border, but no other "natural" ending of the activity. If this is not agreed, the spec needs to explain how to model such activities. ##Proposed Resolution: Fixed at Page 26, Normal Flow row of Table 7.2 replace : "Normal flow refers to the series of Sequence Flow that originates from a Start Event and continues through activities via alternative and parallel paths until it ends at an End Event. This does not include the paths that start from an Intermediate Event attached to the boundary of an Activity." with the following text: "Normal flow refers to paths of Sequence Flow that do not start from an Intermediate Event attached to the boundary of an Activity." beyond that, this issue is resolved by resolution of issue 14783 (Jira issue |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:37 AM ] |
| Lombardi: I believe this is covered in section 10.2 where it says "An Activity MAY be a source for Sequence Flow" and "If the Activity does not have an outgoing Sequence Flow, and there is no End Event for the Process, then the Activity marks the end of one or more paths in the Process." but an explicit statement wouldn't hurt. |
| Comment by Ivana Trickovic [ 02/Nov/09 02:58 AM ] |
| Issue # 14361 is duplicate of issue # 14352. |
| Comment by Stephen White [ 04/Nov/09 01:35 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-04 ----------
This issue was linked to Issue 267. We expect that the resolution for that issue would satisfy this issue, which could then be closed with no change. |
| Comment by Stephen White [ 22/Mar/10 05:49 PM ] |
| proposalScheduledForBallot11 |
| Comment by Hagen Volzer [ 24/Mar/10 11:02 AM ] |
|
New Proposed Resolution: Fixed
Proposal: at Page 26, Normal Flow row of Table 7.2 replace " Normal flow refers to the series of Sequence Flow that originates from a Start Event and continues through activities via alternative and parallel paths until it ends at an End Event. This does not include the paths that start from an Intermediate Event attached to the boundary of an Activity." by "Normal flow refers to paths of Sequence Flow that do not start from an Intermediate Event attached to the boundary of an Activity." beyond that, I think this issue is resolved by resolution for http://www.osoa.org/jira/browse/BPMNFTF-468 |
| Comment by Ivana Trickovic [ 11/Jun/10 10:53 AM ] |
|
spec-May24-review
[AB feedback] Feedback from Steve Cook, Microsoft: Resolution 14352 requires a text substitution: the edit to the actual spec is missing a "to". |
| Comment by Ivana Trickovic [ 11/Jun/10 10:53 AM ] |
|
As per the 6/7 meeting:
Agreed to change the convenience document accordingly |
[BPMNFTF-267] [OMG 14351] Modeling activities that do not complete before process completion
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Won't Fix | Votes: | 0 |
| File Attachments: |
E-Mail 'voting Process - Activities without normal end.jpg
E-Mail Voting Process - Example of Parallel Box.jpg
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14351 Page 26, Normal Flow row of Table 7.2 Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion. There are activities that are never ended - that is they have no natural completion, but are terminated only when the process itself is terminated. Monitoring activities are like that. If an activity is started, and there is never a conclusion of that activity, then this should be indicated by having no outbound arrow from the activity. This activity is concluded only by the termination of the process as a whole. For example, and process may have a main thread, but also split early and start a "monitoring" activity. This monitoring activity is designed to stay active until the process is concluded for some other reason. There is no way for the assignee of the activity to say "I am done monitoring this process" without the process itself being terminated. Since there is no "natural" end of the activity, there should be no arrow coming out of the activity node. I am not sure if this is a requirement of the spec, but there is a common perception that it is a requirement, that all activities have an outbound arrow coming out of it. This request is that the spec include a statement that it is explicitly OK to not have an arrow out of an activity that has no natural end to its execution. If this is not agreed, the spec needs to explain how to model such activities. ##Proposed Resolution: Close; No Change The FTF Team agreed that some examples of modeling techniques that can be used to model these situations would be appropriate. For now, the issue can be Closed; No Change |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:49 AM ] |
|
Lombardi: This seems very similar to |
| Comment by Stephen White [ 02/Nov/09 04:33 PM ] |
|
The relevant sections for discussion of this issue are:
Section 10.2 Activities, subsection "Sequence Flow Connections" -- pages 130-131 of Beta Spec (160-161 PDF) Section 10.4.2 Start Event -- pages 214-215 of Beta Spec (244-245 PDF) Section 10.4.3 End Event -- page 222 of Beta Spec (252 PDF) Section 10.4.5 Intermediate Events, subsection "Sequence Flow Connections" -- pages 235-236 of Beta Spec (265-266 PDF) Section 10.5.1 Sequence Flow Connections (for Gateway) -- pages 265-266 of Beta Spec (295-296 PDF) These sections should be reviewed for completeness and accuracy. |
| Comment by Stephen White [ 02/Nov/09 04:39 PM ] |
| The "Receive Vote" and "Increment Tally" loop do not have a normal end. The will go on indefinitely. The Timer Event attached to the boundary of the Sub-Process is what terminates the loop and the Sub-Process as a whole. Note that the normal end of the Sub-Process (to a top-level End Event) is never taken, but is still required for the model. |
| Comment by Stephen White [ 02/Nov/09 04:42 PM ] |
| This snippet shows a Sub-Process that does not have a Start or End Event. It was this type of functionality that was the motivation to make Start and End Events optional. |
| Comment by Stephen White [ 02/Nov/09 04:44 PM ] |
| This snippet shows an example of a Sub-Process that does not have a Start or End Event. This type of structure was known as a "parallel box" and was the motivation for having Start and End Events optional. |
| Comment by Stephen White [ 04/Nov/09 01:33 PM ] |
|
Discussion during Process Orchestration Sub-Group on 2009-11-04
This issue was lined to Issue 268. We expect that the resolution for this issue would satisfy Issue 268 (which could be closed) Also, in addition to the Sections listed above, we need to look at the Execution semantics section to see if any changes are required. |
| Comment by Stephen White [ 01/Dec/09 09:11 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-25 ----------
No hanging activities. Relaxing these restrictions? It is a best practice to have none. Need to define execution semantics. More problem for Start. Not executable? Not intended to have a virtual Start Event for each dangling element. Needs clarification in the spec. 14.2.1 doesn't mention syntax What is the concept? Either all or none? Is it just best practice. More flexible? Easier to explain? What does it mean to have dangling? Proposed semantics An element without an incoming SF implies an implicit Sequence Flow to that element from to any and ALL Start Events. An element without an outgoing SF implies implicit Sequence Flow and End Event for that element. So, proposal is to relax restrictions and tighten up statements. |
| Comment by Hagen Volzer [ 14/Dec/09 05:15 AM ] |
|
Let me summarize the proposal from the discussion on 2009-11-25:
- propose to not prescribe any incoming or outgoing SF for activities (drop current restrictions) - proposed semantics: start: an element without incoming SF is instantiated on every instantiation of the surrounding process end: an element without outgoing SF is treated as it would be followed by an implicit "none" end event; Note that, according to the termination semantics, the process cannot terminate normally unless all contained activities are completed |
| Comment by Mariano Benitez (Oracle) [ 13/Jan/10 07:46 AM ] |
|
In general I agree with the proposal, removing the restrictions.
But, in my opinion, to implement the monitoring use case, people have to manually add some sort of signal or terminate event in the right place to interrupt the monitoring activities. That can be confusing for people, and also not very easy to maintain. To provide an easy solution to the use case (monitoring activities), I was thinking of something similar to a "weak token", that would not count for the total tokens to wait to terminate the process. Weak tokens would receive a terminate events when the rest of the tokens are completed. Just a thought. |
| Comment by Stephen White [ 27/Jan/10 06:50 PM ] |
|
-------------------- Discussed during Conference Call on 2010-01-27 ---------------------
See comment in http://www.osoa.org/jira/browse/BPMN-468 |
| Comment by Stephen White [ 03/Feb/10 08:46 PM ] |
|
The above link is really:
http://www.osoa.org/jira/browse/BPMNFTF-468 |
| Comment by Hagen Volzer [ 10/Feb/10 12:36 PM ] |
| I have added a proposal to 468, which in part addresses this issue. However that might be not sufficient for this issue. Marianos comment indicates that. Marianos comment suggest changes to the termination semantics (some activities would not need to terminate in order to terminate the process), which is something I am not sure we should do. I will unassign myself from this issue then. |
| Comment by Tom Rutt [ 22/Feb/10 12:27 PM ] |
|
I am not sure what the statement, from proposed resolution to bpmnftf-468,
" - each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event. " buys us. Why cannot the user just draw the explicit sequence flow to an end event? If instead of the above proposed semantics. we just say that an activity without an outgoing SF just terminates when its containing process terminates, the "kill the monitor activity when the process reaches its end" would need no extra notation ?. The original issue asks how you model such a monitoring activity, so if we keep the proposal for 468 as is, then we would need to come up with some extra baggage, such as a "weak token" as Mariano has suggested. What kind of new notational conventions would this entail ? |
| Comment by Hagen Volzer [ 23/Feb/10 02:36 AM ] |
|
Tom,
the point is that the termination semantics of the containing process would need to be redefined, so that the process does not wait for the containing "monitoring" activities. That means that monitoring activities would need to be distinguished from "normal" contained activities. I don't think it would be a good idea to do that just by the fact that they have no outgoing sequence flow. For example, it would not be compatible with BPMN 1.1. |
| Comment by Stephen White [ 24/Mar/10 07:54 PM ] |
| New Proposed Resolution |
| Comment by Stephen White [ 24/Mar/10 07:56 PM ] |
|
------------- Conference Call on 2010-03-24 ---------------------
The resolution for this issue would require changes to activity types, notation, and execution semantics. There is not enough time to do this work in the FTF or to reach a consensus on the resolution. Thus, we propose to defer the issue. |
| Comment by Stephen White [ 29/Mar/10 03:44 PM ] |
|
-------------------- Conference Call on 2010-03-29 ------------------
There was an agreement to change the proposal to Close; No Change, but to add a statement that it would be appropriate to add some examples to show how current modeling techniques could be used to handle the situation. |
[BPMNFTF-266] [OMG 14350] Associating Data Objects with process as a whole
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
Page 22, Section 7.2.1 - Associating Data Objects with process as a whole Many workflow systems are designed around the concept that there is a process context that holds variables shared by all activities within that context. Since the swimming pool represents the process instance as a whole, there should be a way to associated process variables with the pool itself, which would be accessible by all activities within the pool. The spec should clarify how a model can associate data objects with the process as a whole. -------------------- Proposal ----------- 2009-11-16 --------------------------------- ##Proposed Resolution: Closed; No Change Processes define DataObjects, so the scope of DataObjects is the process they are defined. We are opening another issue to create a clarification of the behaviour of simultaneous updates on DataObjects. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:55 AM ] |
| Lombardi: Doesn't this introduce problems with synchronizing access to such variables when there are parallel flows executing? |
| Comment by Stephen White [ 04/Nov/09 01:41 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-11-04 ----------
There seems to be some confusion with the issue description between Pool and Process. These are different and Pools do not have data, Processes do. Data Objects are already accessible to all activities. So are Process Properties, which are non-graphical. We propose to Close issue with no change. Add an explanation. I will reassign and take care of proposal. There is a Comment regarding parallel flows and Synchronizing data. only affected by writing data. Writing to data objects need understanding by modeling. We think that the spec is silent on this issue (but need to verify. Maybe should have a new issue to add text to execution semantics section. Alex or anyone else should review the text and determine if some explanation is required. Then a separate issue could be generated for that topic. |
| Comment by Mariano Benitez (Oracle) [ 13/Nov/09 01:19 PM ] |
|
I agree with Steve, Processes have data, Pools refer to processes and they don't define data.
I agree with his proposal of closing with no change, and opening a new issue for the sync problem writing info to data objects in parallel. |
[BPMNFTF-265] [OMG 14349] Fork and Join Differentiation
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Fujitsu (Tom Rutt tom@coastin.com)
This is issue # 14349 Page 29, Section 7.2.2 - Fork and Join Differentiation BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence of parallel paths, and another AND gateway to end it. The behaviors of these two gateways are different, but they look the same. Suggestion is that the first AND gateway, that starts the parallel split have a thin line, while the gateway at the end which actually waits for multiple inputs will have a thick line. This corresponds to the thin and thick lines around start and end nodes. -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Defer We agree to leave this issue in the wish list for the RTF -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 09:14 AM ] |
| Lombardi: I don't think this is needed. The two different roles for the parallel gateway can be distinguished by whether there are multiple lines leaving or entering the gateway. |
| Comment by Mariano Benitez (Oracle) [ 13/Nov/09 01:15 PM ] |
|
Couple comments:
1) we (oracle) believe it is important to differentiate the converging and diverging gateways, and not just infer the intention from the sequence flows. we do like users to define the intention of the gateway (3 modes), and then validate that the sequence flows match the intention. Consequently we are in favor of displaying a differentiation. 2) our proposal is to draw a thick line on the left when the gw is diverging and on the right when it is converging. no think line when it is mixed or undefined. Essentially we have 3 possible graphical states. 3) What I don't like about Tom's proposal is that there's no room for the other 2 possble states (mixed or undefined). Here there are only 2 graphical states which make it harder to distinguish. |
| Comment by Stephen White [ 09/Dec/09 04:28 PM ] |
|
--------------- Discussion during F2F/Call on 2009-12-09 ----------------------------------
We agreed to defer the issue. |
[BPMNFTF-264] [OMG 14347] Page 190, sub-section "Transaction"
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Additional Transaction Figure.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 158, sub-section "Transaction" Can a Transaction Sub-Process be presented collapsed? i.e with a + marker at the bottom center. NB It is clear in the case of Event Subprocess -------------------- Proposal ----------- 2009-11-30 --------------------------------- ##Proposed Resolution: Fixed A new figure will be added in Section 10.2.5 after Figure 10.32. The figure will be the one shown posted here: http://www.osoa.org/jira/secure/attachment/10563/10563_Additional+Transaction+Figure.jpg ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 09:18 AM ] |
| Lombardi: Agree that needs clarification. I think collapsed presentation should be allowed. |
| Comment by Stephen White [ 23/Nov/09 07:26 PM ] |
|
All Sub-Processes can be displayed either expanded or collapsed. This, then, is true for a Transaction.
No additional marker is needed for the collapsed version since the Transaction has a double-lined boundary. |
| Comment by Stephen White [ 23/Nov/09 07:29 PM ] |
|
-------------------- Proposal ----------- 2009-11-23 ---------------------------------
Close; no change. A Transaction can be collapsed like any other Sub-Process. The double-lined boundary would be used for both collapsed and expanded versions. ----------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 30/Nov/09 01:25 PM ] |
|
-------------------- Proposal ----------- 2009-11-30 ---------------------------------
Add the attached figure after figure 10.32. ----------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 23/Apr/10 06:46 AM ] |
| Updated page and Chapter based on Beta 1 |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-263] [OMG 14346] Page 076, Figure 8-5, Figure Caption incorrect
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 076, Figure 8-5, Figure Caption incorrect Reported by dga...@trisotech.com, Jul 29, 2009 Figure 8-5 is named "Classes in the Infrastructure package". This figure is presented in the section "8.2 Foundation". Is the caption incorrect? -------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Fixed Section 8.2 Foundation, page 45 (75 pdf), Figure 8.5: Replace current figure title with the following text: "Classes in the Foundation Package" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 09:27 AM ] |
| Lombardi: Caption looks odd to me too. It includes classes from the Infrastructure and Foundation packages. |
| Comment by Stephen White [ 10/Nov/09 06:46 PM ] |
|
-------------------- Proposal ---------- 2009-11-10 -------------------------------------
##Proposed Resolution: Fixed Section 8.2 Foundation, page 45 (75 pdf), Figure 8.5: Replace current figure title with the following text: "Classes in the Foundation Package" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-262] [OMG 14345] Page 032, section 2.4.1, Referencing wrong chapter
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 032, section 2.4.1, Referencing wrong chapter Reported by dga...@trisotech.com, Jul 29, 2009 Second bullet of section 2.4.1 is: "Choreography diagrams, which includes the elements defined in the Choreography, and Choreography packages (see Chapter 10)." The reference should be to Chapter 12. Third bullet of section 2.4.1 See Chapter 143 should read Chapter 9 -------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Fixed (a) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), first bullet on page: Change "Chapter 70" to "Chapter 8" (b) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), second bullet on page: Change "Chapter 10" to "Chapter 12" (c) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), third bullet on page: Change "Chapter 143" to "Chapter 9" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 10/Nov/09 07:01 PM ] |
|
-------------------- Proposal ---------- 2009-11-10 -------------------------------------
##Proposed Resolution: Fixed (a) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), first bullet on page: Change "Chapter 70" to "Chapter 8" (b) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), second bullet on page: Change "Chapter 10" to "Chapter 12" (c) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), third bullet on page: Change "Chapter 143" to "Chapter 9" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
| Comment by Denis Gagne [ 12/May/10 09:47 AM ] |
|
Spec-Draft3-review
section 2.4.1 point (b) should really now point to chapter 11 due to chapter removal |
| Comment by Ivana Trickovic [ 17/May/10 03:18 PM ] |
| As per the meeting of May 17th: Agreed that this needs to be fixed |
| Comment by Stephen White [ 18/May/10 02:00 PM ] |
| Done |
[BPMNFTF-261] [OMG 14344] Page 361, Figure 12-23, Sub-process marker missing
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Replacement for Figure 12.23.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=158 Page 361, Figure 12-23, Sub-process marker missing Reported by dga...@trisotech.com, Jul 29, 2009 The Figure 12-23 shows a Choreography Sub-Process. However the + marker is missing. In addition the caption of the figure should be "Choreography Sub-Process with multi-instance Participants". -------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Fixed (a) Section 12.4.2 Choreography Sub-Process, page 325 (355 pdf), Figure 12.23: Replace current figure with the figure posted here: http://www.osoa.org/jira/secure/attachment/10560/Replacement+for+Figure+12.23.jpg. (b) Section 12.4.2 Choreography Sub-Process, page 325 (355 pdf), Figure 12.23: append current figure title with the following text: " with a multi-instance Participant" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Alex Moffat [ 15/Sep/09 08:50 PM ] |
| Lombardi: It looks like 12-23 is just a direct copy of 12-15 instead of being a drawing of a choreography sub-process as it should be. |
| Comment by Stephen White [ 10/Nov/09 06:26 PM ] |
|
-------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Fixed Section 12.4.2 Choreography Sub-Process, page 325 (355 pdf), Figure 12.23: Replace current figure with the attached figure. -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-260] [OMG 14343] Page 337, section 11.5 Typo should be "Call Conversation"
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=157 Page 337, section 11.5 Typo should be "Call Conversation" Reported by dga...@trisotech.com, Jul 29, 2009 Second structural specification should be "Call Conversation" instead of "Call Activity" -------------------- Proposal ----------- 2009-10-27 --------------------------------- ##Proposed Resolution: Fixed Section 11.5, page 301 (page 331 pdf), second bullet on page: change "Call Activity" to "Call Conversation." ------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 27/Oct/09 06:32 PM ] |
|
-------------------- Proposal ----------- 2009-10-27 ---------------------------------
Section 11.5, page 301 (page 331 pdf), second bullet on page: change "Call Activity" to "Call Conversation." ------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-259] [OMG 14342] Page 331, Figure 11-4, Message Flows part of a Conversation diagram
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Figure 11-4 Updated.jpg
Figure 11-5 [New Figure].jpg
Figure 11-6 [New Figure].jpg
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=156 Page 331, Figure 11-4, Message Flows part of a Conversation diagram Reported by dga...@trisotech.com, Jul 29, 2009 Figure 11-4 presents a list of Message Flows associated to the "DeliveryNegotiations Conversation". Are the message flows listed the correct depiction for the explosion ofthe Conversation? If so shouldn't the conversation object have a [+]? Are Message Flows graphical elements to be used in a Conversation diagram or was it presented exclusively to show the relation between two views? ##Proposed Resolution: Fixed Note that all of these changes will be moved to Chapter 9 Collaboration through the resolution of issue 14654. (a) Paragraph above Figure 11.4: replace first sentence with the following: "Figure 11.4 shows a subset of the larger Conversation diagram of Figure 11.3, above. Figures 11.5 and 11.6 show the drill down into the "Delivery Negotiations" Sub-Conversation." (b) Replace Figure 11.4 with a figure that only shows the two Pools, two Conversation Links, and a Sub-Conversation element (the plus sign that was missing should be added) - the bottom half of the figure would be removed. See attached figure http://www.osoa.org/jira/secure/attachment/10547/10547_Figure+11-4+Updated.jpg. (c) Replace the caption for Figure 11.4 with the following: "An example of a Sub-Conversation" (d) Add a figure after Figure 11.4 that shows the expanded version of the Sub-Conversation so that it contains a set of reference Message Flow and Conversation element ("Variations"). See attached figure http://www.osoa.org/jira/secure/attachment/10690/10690_Figure+11-5+%5BNew+Figure%5D.jpg (e) The caption for the new figure should be the following: "An example of a Sub-Conversation expanded to a Conversation and Message Flow" (f) Add a new paragraph that precedes the new figure: "Figure 11.5 shows a how the Sub-Conversation of Figure 11.4 is expanded into a set of Message Flow and a lower-level Conversation." (g) Add another new figure (after item (d)) that shows the Sub-Conversation expanded fully to all of its referenced Message Flow. See attached figure http://www.osoa.org/jira/secure/attachment/10549/10549_Figure+11-6+%5BNew+Figure%5D.jpg (h) The caption for the new figure should be the following: "An example of a Sub-Conversation that is fully expanded" (i) Add a new paragraph that precedes the new figure: "Figure 11.6 shows a how the Conversation of Figure 11.5 is also expanded into a set of Message Flow, combined with the Message Flow. Note that the newly exposed Message Flow of the lower-level Conversation will be correlated by the CorrelationKey of both the lower-level Conversation ("Variation ID") and the higher-level Sub-Conversation ("Order ID")." |
| Comments |
| Comment by Stephen White [ 15/Oct/09 09:38 PM ] |
|
This will replace the current 11-4 Text changes will be posted separately. |
| Comment by Stephen White [ 15/Oct/09 09:39 PM ] |
| The new Figure 11-5 will be used with 11-4 and 11-6 to show the dtrill down of Conversations to Message Flow |
| Comment by Stephen White [ 22/Mar/10 05:12 PM ] |
| proposalScheduledForBallot11 |
| Comment by Conrad Bock (NIST) [ 17/Apr/10 03:26 PM ] |
|
-----------Proposal----------------Apr 17, 2010---------------------------
##Proposed Resolution: Defer Note that all of these changes will be moved to Chapter 9 Collaboration through the resolution of issue 14654. (a) Paragraph above Figure 11.4: replace first sentence with the following: "Figure 11.4 shows a subset of the larger Conversation diagram of Figure 11.3, above. Figures 11.5 and 11.6 show the drill down into the "Delivery Negotiations" Sub-Conversation." (b) Replace Figure 11.4 with a figure that only shows the two Pools, two Conversation Links, and a Sub-Conversation element (the plus sign that was missing should be added) - the bottom half of the figure would be removed. See attached figure http://www.osoa.org/jira/secure/attachment/10547/10547_Figure+11-4+Updated.jpg. (c) Replace the caption for Figure 11.4 with the following: "An example of a Sub-Conversation" (d) Add a figure after Figure 11.4 that shows the expanded version of the Sub-Conversation so that it contains a set of reference Message Flow and Conversation element ("Variations"). See attached figure http://www.osoa.org/jira/secure/attachment/10690/10690_Figure+11-5+%5BNew+Figure%5D.jpg (e) The caption for the new figure should be the following: "An example of a Sub-Conversation expanded to a Conversation and Message Flow" (f) Add a new paragraph that precedes the new figure: "Figure 11.5 shows a how the Sub-Conversation of Figure 11.4 is expanded into a set of Message Flow and a lower-level Conversation." (g) Add another new figure (after item (d)) that shows the Sub-Conversation expanded fully to all of its referenced Message Flow. See attached figure http://www.osoa.org/jira/secure/attachment/10549/10549_Figure+11-6+%5BNew+Figure%5D.jpg (h) The caption for the new figure should be the following: "An example of a Sub-Conversation that is fully expanded" (i) Add a new paragraph that precedes the new figure: "Figure 11.6 shows a how the Conversation of Figure 11.5 is also expanded into a set of Message Flow, combined with the Message Flow. Note that the newly exposed Message Flow of the lower-level Conversation will be correlated by the CorrelationKey of both the lower-level Conversation ("Variation ID") and the higher-level Sub-Conversation ("Order ID")." |
[BPMNFTF-257] [OMG 14340] Page 265, Sequence Flow Connections for Intermediate Events
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=154 Page 265, Sequence Flow Connections for Intermediate Events Reported by dga...@trisotech.com, Jul 29, 2009 A structual specification says:"The Intermediate Events with the following Triggers MAY be used in normal flow: None, Message, Timer, Compensation, Conditional, Link, and Signal. Thus, the following MUST NOT: Canvel, Error, Multiple and Parallel Multiple." However, Table 10-82 (page 259) says for both (Multiple and Parallel Multiple Events) "If used within normal flow, the event can catch ...". Are Multiple and Paralle Multiple Events allowed on the normal flow? Also Escalation is missing from the list of MAY be used in normal flow ---------------------- Proposed Resolution -------- 2010-04-02 --------------------- ##Proposed Resolution: Fixed Move Multiple and Parallel Multiple to the list of Event types that may be used in normal flow. Add Escalation to the list of Event types that may be used in normal flow. (a) Section 10.4.4, Sub-Section Sequence Flow Connections: replace 7th bullet on page with the following: "The Intermediate Events with the following Triggers (EventDefinition) MAY be used in normal flow: None, Message, Timer, Escalation, Compensation, Conditional, Link, Signal, Multiple, and Parallel Multiple. Thus, the following MUST NOT: Cancel and Error." |
| Comments |
| Comment by Ivana Trickovic [ 04/Nov/09 09:26 AM ] |
| Editorial, but proposal needs to be reviewed (it may include normative text). |
| Comment by Ivana Trickovic [ 10/Mar/10 11:17 PM ] |
|
As per March F2F Meeting:
- Make sure that the list is aligned with table 10.82. |
| Comment by Stephen White [ 22/Mar/10 05:08 PM ] |
| proposalScheduledForBallot11 |
| Comment by Stephen White [ 02/Apr/10 03:53 PM ] |
| New Proposed Resolution |
[BPMNFTF-256] [OMG 14341] Page 328, Section 11, Communication Link or Conversation Link
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=155 Page 328, Section 11, Communication Link or Conversation Link Reported by dga...@trisotech.com, Jul 29, 2009 At beginnig of section 11 it says: "The view includes two(2) additional graphical elements that do not exist in other BPMN views: A Communication, A CommunicationLink." The title of section 11.7 at page 338 is "Communicaion Link", however the descriptive text anf Figure refer to "Conversation Link". The graphical element a "Communication Link" should be "Conversation Link"? ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 15/Oct/09 06:17 PM ] |
| We will postpone a proposal for this issue for now. We are expecting an issue to be posted that will request that the Collaboration and Conversation diagrams be consolidated. If this new issue is resolved in that way, then it will affect this issue. Thus, we will wait for the resolution of the new issue before we decide if we need to do any additional work for this issue. |
| Comment by Stephen White [ 22/Mar/10 05:00 PM ] |
| New Proposed Resolution |
[BPMNFTF-255] [OMG 14339] Page 265, Activity Boundary Connections
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=153 Page 265, Activity Boundary Connections Reported by dga...@trisotech.com, Jul 29, 2009 In the structural specifications under "Activity Boundary Connections" the list of Intermediate Events that can be attached is provided (second structural spec.). In the structural specifications under "Sequence Flow Connections" the same list is provided (first sttructural spec.). Is it required to duplicate the list? The content of the list is different, Escalation is not included in the second list. ------------- New Proposed Resolution ---------- 2010-02-11 ------------------------------- ##Proposed Resolution: Fixed Remove redundant text from the Sequence Flow considerations of an Intermediate Event. (a) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Remove first bullet in section (b) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Change indent level to the left for the next bullet (after removing the first bullet ---------------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 11/Feb/10 09:43 PM ] |
|
------------- New Proposed Resolution ---------- 2010-02-11 -------------------------------
Remove redundant text from the Sequence Flow considerations of an Intermediate Event. (a) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Remove first bullet in section (b) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Change indent level to the left for the next 5 bullets (after removing the first bullet ---------------------------------------------------------------------------------------------------------------- |
[BPMNFTF-254] [OMG 14338] Page 257, Intermediate Event Types in Normal flow
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=152 Page 257, Intermediate Event Types in Normal flow Reported by dga...@trisotech.com, Jul 29, 2009 The sentence above Table 10-82 says: "Nine(9) of the eleven (11) Intermediate Event ...." Table 10-82 shows 10 Events and not 9 and page 256 indicates and lists twelve (12) Intermediate Events. ------------------------ New Proposed Resolution ----------- 2010-01-21 ---------------------------- ##Proposed Resolution: Fixed Section 10.4.4, page 226 (256 pdf), last sentence on page: change "Nine (9) of the eleven (11)" to "Ten (10) of the twelve (12)" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 21/Jan/10 11:41 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-21 ----------------------------
Section 10.4.4, page 226 (256 pdf), last sentence on page: change "Nine (9) of the eleven (11)" to "Ten (10) of the twelve (12)" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-253] [OMG 14337] Page 255, Message Flow connection for End Event
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=151 Page 255, Message Flow connection for End Event Reported by dga...@trisotech.com, Jul 29, 2009 The last two structural speficication at bottom of page 255 have errors. The first one has an extra sentence starting with If the Intermediate Event... The second structural specification should not be there. (BTW bullet should be diamonds here and many other places) -------------------- Proposal ----------- 2009-11-22 --------------------------------- ##Proposed Resolution: Fixed The End Event Message Flow Connection definitions should have a parallel construction as the Start Event Message Flow Connections. Thus, the following changes will be made to the specification: (a) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), first bullet in section: Delete second sentence of bullet item. (b) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), second bullet in section: Delete entire bullet item and replace with the following text, "An End Event MAY be the source for Message Flow; it can have 0 (zero) or more outgoing Message Flow. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered." (c) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the following text, "The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flow." (d) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the following text, "The Result attribute of the End Event MUST be set to Multiple if there is more than one (1) outgoing Message Flow." ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 22/Nov/09 09:51 PM ] |
|
-------------------- Proposal ----------- 2009-11-22 ---------------------------------
The End Event Message Flow Connection definitions should have a parallel construction as the Start Event Message Flow Connections. Thus, the following changes will be made to the specification: (a) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), first bullet in section: Delete second sentence of bullet item. (b) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), second bullet in section: Delete entire bullet item and replace with the following text, "An End Event MAY be the source for Message Flow; it can have 0 (zero) or more outgoing Message Flow. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered." (c) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the following text, "The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flow." (d) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the following text, "The Result attribute of the End Event MUST be set to Multiple if there are more than one (1) outgoing Message Flow." ----------------------------------------------------------------------------------------------- |
| Comment by Andrea Westerinen [ 15/Dec/09 03:36 PM ] |
|
The grammar in (d) needs to be corrected ...
"The Result attribute ... if there IS more than one (1) outgoing Message Flow." |
| Comment by Stephen White [ 13/Jan/10 04:16 PM ] |
| The proposal was updated to address Andrea's comment. The change in the text was also made. There was one other occurrence of this situation. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-252] [OMG 14336] Page 253, section 10.4.3 End Event Sequence Flow Connections
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=150 Page 253, section 10.4.3 End Event Sequence Flow Connections Reported by dga...@trisotech.com, Jul 29, 2009 The third structural specifications for an End Event in page 253 reads:"If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e. are not a source of a Sequence Flow) mark the end of a path in the Process." Is a "Throwing Link Intermediate Event" an exception to this statement? And, should it be indicated? -------------------- Proposal ----------- 2009-11-23 --------------------------------- ##Proposed Resolution: Fixed (a) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this are throwing Link Intermediate Events, which are not allowed to have outgoing Sequence Flow. See page 243 for more information on Link Intermediate Events." (b) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this are Event Sub-Processes which are not allowed to have outgoing Sequence Flow. See page 155 for more information on Event Sub-Processes." ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Nov/09 05:37 PM ] |
|
-------------------- Proposal ----------- 2009-11-23 ---------------------------------
(a) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this are throwing Link Intermediate Events, which are not allowed to have outgoing Sequence Flow. See page 243 for more information on Link Intermediate Events." (b) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this are Event Sub-Processes which are not allowed to have outgoing Sequence Flow. See page 155 for more information on Event Sub-Processes." ----------------------------------------------------------------------------------------------- |
| Comment by Andrea Westerinen [ 15/Dec/09 03:35 PM ] |
|
The grammar needs to be corrected ....
"An exception to this IS throwing ..." "An exception to this IS Event Sub-Processes ..." |
| Comment by Ivana Trickovic [ 03/May/10 08:40 AM ] |
|
Beta 1, Draft 2:
I could not track the changes. Probably the resolution has been removed as part of another resolution. |
| Comment by Stephen White [ 03/May/10 07:42 PM ] |
| These additions were removed by the resolution for issue 14783 (JIRA 468). I made an annotation in the spec to clarify this. |
[BPMNFTF-251] [OMG 14335] Page 192, Table 10-21 Transaction types need explanation
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Metamodel, Process Orchestration, Schema |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=149 Page 192, Table 10-21 Transaction types need explanation Reported by dga...@trisotech.com, Jul 29, 2009 At p. 192 of the specification, the TransactionMethod can be of type Compensate, Store,Image. A small text describing these variants would be useful, since only stating terms can lead to various interpretation. The same issue apply for the BPMN 1.2 specification at (p.281) B.11.19. ##Proposed Resolution: Fixed Table 10.21: Current: method: TransactionMethod = compensate { compensate | store | image } TransactionMethod is an attribute that defines the technique that will be used to undo a Transaction that has been cancelled. The default is compensate, but the attribute MAY be set to store or IMAGE. New: method: string TransactionMethod is an attribute that defines the transaction method used to commit or cancel a transaction. For executable processes, it SHOULD be set to a technology specific URI, e.g., http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, or http://docs.oasis-open.org/ws-tx/wsba/2006/06/AtomicOutcome for WS-BusinessActivity. For compatibility with BPMN 1.1, it can also be set to "##compensate", "##store", or "##image". |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 11:27 PM ] |
|
As per March F2F Meeting:
- This issue needs to be addressed. Take the same approach as for business rules implementation attribute (which has been changed to URI). Resolve in the spirit of |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:31 AM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:55 AM ] |
|
Proposed changes:
Table 10.21: Current: method: TransactionMethod = compensate { compensate | store | image } TransactionMethod is an attribute that defines the technique that will be used to undo a Transaction that has been cancelled. The default is compensate, but the attribute MAY be set to store or IMAGE. New: method: string TransactionMethod is an attribute that defines the transaction method used to commit or cancel a transaction. For executable processes, it SHOULD be set to a technology specific URI, e.g., http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, or http://docs.oasis-open.org/ws-tx/wsba/2006/06/AtomicOutcome for WS-BusinessActivity. For compatibility with BPMN 1.1, it can also be set to "##compensate", "##store", or "##image". |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 03:56 AM ] |
| newProposedResolution |
| Comment by Denis Gagne [ 12/May/10 10:04 AM ] |
|
Spec-Draft3-review
The attribute and description may lead to confusion for the reader. The attribute name is method and the description talks of the TransactionMethod attribute. |
| Comment by Suzette Samoojh (IBM) [ 17/May/10 11:17 AM ] |
|
Table 10-50 in Draft 3 does not contain content from the actual XSD.
Correct content: <xsd:element name="transaction" type="tTransaction" substitutionGroup="flowElement"/> <xsd:complexType name="tTransaction"> <xsd:complexContent> <xsd:extension base="tSubProcess"> <xsd:attribute name="method" type="tTransactionMethod" default="##Compensate"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:simpleType name="tTransactionMethod"> <xsd:union memberTypes="xsd:anyURI"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="##Compensate" /> <xsd:enumeration value="##Image" /> <xsd:enumeration value="##Store" /> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType> |
| Comment by Ivana Trickovic [ 17/May/10 03:17 PM ] |
|
As per the meeting of May 17th:
Agreed to make the following changes: - In the specification, change "TransactionMethod" to "method" in the second column (attribute description) - Update the XSD accordingly - MM is ok |
| Comment by Suzette Samoojh (IBM) [ 18/May/10 09:02 AM ] |
|
No, the snippet I posted is the right snippet.
Copying my email response here: The TransactionMethod is still needed in the XSD. It captures the possible values (either a URI or one of ##Compensate, ##Image, ##Store). Also note that this is the same pattern we applied for other similar resolutions (e.g. http://www.osoa.org/jira/browse/BPMNFTF-286) So I see no XSD changes, but just a need to update the snippet in the spec. |
| Comment by Ivana Trickovic [ 18/May/10 09:19 AM ] |
|
Suzette's proposal for XSD looks ok. It could be considered as a refined version of the initial proposal.
But the specification text still needs to be updated as suggested during the call. Change "TransactionMethod is an attribute that defines the transaction method used to commit or cancel a transaction. " to "The method attribute defines the transaction method used to commit or cancel a transaction. " Plus: Change "method: string" to "method: TransactionMethod" |
| Comment by Stephen White [ 18/May/10 01:43 PM ] |
| Done |
[BPMNFTF-250] [OMG 14334] Page 251, Exceptions for Sequence Flow connections for Start Event
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 4 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=148 Page 251, Exceptions for Sequence Flow connections for Start Event Reported by dga...@trisotech.com, Jul 29, 2009 In the structural specification on Sequence Flow Connections (page 251)it is written:"When a Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow SHALL be the start of a separate parallel path. Event Sub-process and Catching Intermediate Event Link are also exceptions to that? -------------------- Proposal ----------- 2009-11-24 --------------------------------- ##Proposed Resolution: Fixed (a) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are catching Link Intermediate Events, which are not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events." (b) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are Event Sub-Processes, which are not allowed to have incoming Sequence Flow. See page 155 for more information on Link Intermediate Events." ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 24/Nov/09 05:38 PM ] |
|
-------------------- Proposal ----------- 2009-11-24 ---------------------------------
(a) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are catching Link Intermediate Events, which are not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events." (b) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are Event Sub-Processes, which are not allowed to have incoming Sequence Flow. See page 155 for more information on Link Intermediate Events." ----------------------------------------------------------------------------------------------- |
| Comment by Andrea Westerinen [ 15/Dec/09 03:34 PM ] |
|
The grammar needs to be corrected in both fixes ...
"An exception to this IS catching ..." "An exception to this IS Event Sub-Processes ..." |
| Comment by Ivana Trickovic [ 03/May/10 08:40 AM ] |
|
Beta 1, Draft 2:
I could not track the changes. Probably the resolution has been removed as part of another resolution. |
| Comment by Stephen White [ 03/May/10 07:37 PM ] |
| These changes were replaced by changes for issue 14331 (JIRA 247). An annotation for this was clarified in the spec. |
[BPMNFTF-249] [OMG 14333] Page 251, Start Event on the boundary of a sub-process
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=147 Page 251, Start Event on the boundary of a sub-process Reported by dga...@trisotech.com, Jul 29, 2009 Is it still allowed to have Start and End Event on the boundary of an expended Sub-process? This was clearly stated and shown in BPMN 1.2. It is mentionned at page 251, but no example are provided. Is figure 7-8 page 69 valid? ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:58 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:31 PM ] |
| Move it on ballot #11 and as this could be an implementation issue (possible ambiguity). This issue shall either be fixed or closed. but not deferred. |
[BPMNFTF-248] [OMG 14332] Page 247 section Start Event for Event Sub-Processes
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=146 Page 247 section Start Event for Event Sub-Processes Reported by dga...@trisotech.com, Jul 29, 2009 The first sentence says:" A Start Event can also initiate an inline EventSub-Process (see page 188). In that case, the same Event types as for boundary Events are allowed (see Table 10-79), namnely: Message, timer, Escalation, Error, Cancel, Compensation, Conditional, Signal, Multiple,and Parallel." Cancel should be removed from the list. ------------------------ New Proposed Resolution ----------- 2010-01-21 ---------------------------- ##Proposed Resolution: Fixed Section 10.4.2, Sub-Section "Start Events for Event Sub-Processes," page 217 (247 pdf), first paragraph: remove "Cancel" from the list of Event types ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 21/Jan/10 09:37 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-21 ----------------------------
Section 10.4.2, Sub-Section "Start Events for Event Sub-Processes," page 217 (247 pdf), first paragraph: remove "Cancel" from the list of Event types ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-247] [OMG 14331] Page 244, section 10.4.2 Last two structural specifications for Start Event
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
In the last two structural specifications of page 244: Should Event Sub-process be added to the exceptions that any other elements must not have incoming Sequence Flow when a Start Event is used? ------------------------ New Proposed Resolution ----------- 2010-01-24 ---------------------------- ##Proposed Resolution: Fixed The correction to the first structural specification was defined by the resolution of (a) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary)." (b) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a catching Link Intermediate Event, which is not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events." (c) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this is an Event Sub-Process, which is not allowed to have incoming Sequence Flow and will only be instantiated when its Start Event is triggered. See page 155 for more information on Event Sub-Processes." ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Ivana Trickovic [ 04/Nov/09 09:26 AM ] |
| Editorial |
| Comment by Stephen White [ 24/Jan/10 09:07 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-24 ----------------------------
The correction to the first structural specification was defined by the resolution of Issue 14334 (JIRA 250). The remaining items are for the correction to the second structural specification. (a) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary)." (b) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a catching Link Intermediate Event, which is not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events." (c) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this is an Event Sub-Process, which is not allowed to have incoming Sequence Flow and will only be instantiated when its Start Event is triggered. See page 155 for more information on Event Sub-Processes." ------------------------------------------------------------------------------------------------------------------------ |
| Comment by Mariano Benitez (Oracle) [ 17/May/10 10:15 AM ] |
|
Spec-Draft3-review
if item (a) applied? I cannot find a reference to item (a) of the issue, there are references to (b) and (c). |
| Comment by Ivana Trickovic [ 17/May/10 03:40 PM ] |
| As per the meeting of May 17th: Steve to check. Agreed that this needs to be fixed |
| Comment by Stephen White [ 18/May/10 01:34 PM ] |
| Item a was overridden by another issue. I added a comment in the convenience document to say this. |
[BPMNFTF-246] [OMG 14330] Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=144 Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess Reported by dga...@trisotech.com, Jul 29, 2009 Sub-process markers are presented at pages 186-187. Does these markers (Compensation, Ad Hoc, Loop and MI) also apply to Call Activity and Event Sub-process? Is it none, some or all of them? According to the Class diagrams a Call Activity could not be Adhoc, but since a Call Activity extends from Activity it could be Loop or Compensation or Multi-instance? According to the same logic, an Event Subprocess could also have the same behavior plus Ad hoc. We feel these explicit lists should be presented in the spec instead of inferred from the class diagrams. ##Proposed Resolution: Duplicate The resolution of this issue is part of The new Chapter 13 contains a section that describes in detail which combinations are allowed: 3.2.1 Markers for Activities Various BPMN Activities can be decorated with markers at the bottom center of the shape. Loop Characteristic markers may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask, SendTask, ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. Note that Loop Characteristic Markers (Loop, Multi-Instance - Parallel and Multi-Instance - Sequential) are mutually exclusive markers. That is, only one of them can be present on a single shape. See Table 8 - Depiction Resolution for Loop Characteristic Markers. A Compensation marker may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask, SendTask, ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. See Table 9 - Depiction Resolution for Compensation Marker In the case of expandable kind of shapes, the markers (Compensation or Loop Characteristic) are placed to the left of the + on the shape. The Compensation marker may be combined with a Loop Characteristic Marker. All the markers that are present must be grouped and the whole group centered to the bottom of the shape. See Figure 3 2 - Combined Compensation and Loop Characteristic Marker Example. Note that the in the case where the referenced BPMN model element [bpmnElement] of a BPMNShape is an AdHocSubProcess, the shape has its tilde marker to the right of the + (See section 3.2.6). |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:57 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:29 PM ] |
| Move it on ballot #11 and check with the DI sub-team as this could be an implementation issue (possible ambiguity). |
| Comment by Reiner Hille-Doering [ 19/Apr/10 06:18 AM ] |
|
##Proposed Resolution: Fixed
The new Chapter 13 contains a section that describes in detail which combinations are allowed: 3.2.1 Markers for Activities Various BPMN Activities can be decorated with markers at the bottom center of the shape. Loop Characteristic markers may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask, SendTask, ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. Note that Loop Characteristic Markers (Loop, Multi-Instance - Parallel and Multi-Instance - Sequential) are mutually exclusive markers. That is, only one of them can be present on a single shape. See Table 8 - Depiction Resolution for Loop Characteristic Markers. A Compensation marker may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask, SendTask, ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. See Table 9 - Depiction Resolution for Compensation Marker In the case of expandable kind of shapes, the markers (Compensation or Loop Characteristic) are placed to the left of the + on the shape. The Compensation marker may be combined with a Loop Characteristic Marker. All the markers that are present must be grouped and the whole group centered to the bottom of the shape. See Figure 3 2 - Combined Compensation and Loop Characteristic Marker Example. Note that the in the case where the referenced BPMN model element [bpmnElement] of a BPMNShape is an AdHocSubProcess, the shape has its tilde marker to the right of the + (See section 3.2.6). |
| Comment by Ivana Trickovic [ 19/Apr/10 06:19 AM ] |
|
Moved in balot #12 as it is part of the proposal for |
[BPMNFTF-245] [OMG 14329] Page 159, Section 10.1.2 number of types of diagrams
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Section 10.1.2, first sentence reads: "Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in both types of diagrams." Is the last part of the sentence, which reads: "they are used in both types of diagrams." applies to only two of them, which one are they? If not, the term "both" should be replaced by "all" or eliminated, or this statement reworked. ##Proposed Resolution: Fixed In Section 10.1.2 Use of BPMN Common Elements - first paragraph Replace the phrase: "they are used in both types of diagrams." With: "they are used in these diagrams." |
[BPMNFTF-244] [OMG 14328] Page 153, Figure10-1, Link Events not paired may lead to confusion
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Replacement for Figure 10.1.jpg
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=142 Page 153, Figure10-1, Link Events not paired may lead to confusion Reported by dga...@trisotech.com, Jul 29, 2009 In figure 10-1 the throwing Link Intermediate Event and the catching Link Intermediate Event may lead to confusion to the reader, i.e. someone could think that they should be paired where probably this is a diagram fragment and they should not be paired. The diagram presented is not a complete process but a fragment of a process due to the presence of Intermediate Link Events not paired and the "Discussion Cycle" Sub-process without not directing to a proper "End". Should the diagram be replaced or an identification provided that it shows an incomplete fragment of a larger process? ------------------------ New Proposed Resolution ----------- 2010-01-21 ---------------------------- ##Proposed Resolution: Fixed To avoid the potential confusion mentioned in the issue, replace Figure 10.1, page 121 (151 pdf) with the figure seen here: http://www.osoa.org/jira/secure/attachment/10589/10589_Replacement+for+Figure+10.1.jpg ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 22/Jan/10 12:21 AM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-21 ----------------------------
To avoid the potential confusion mentioned in the issue, replace Figure 10.1, page 121 (151 pdf) with the attached figure ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-243] [OMG 14327] Page 070, section 8 list of Core elements
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=141 Page 070, section 8 list of Core elements Reported by dga...@trisotech.com, Jul 29, 2009 The figure 8-1 indicates "Infrastructure, Common Elements, and Services". Three Core sub-packages are listed in page 71 "Foundation, Service, and Common". Figure 8-2 shows "Foundation, Common, and Service". Section 8.1 describes "Infrastructure", Section 8.2 describes "Foundation", Section 8.3 describes "Common Elements" and Section 8.4 describes "Services". The list of BPMN core elements indicated in thre first bullet of section 2.1.1 is: "Infrastructure, Foundation, Common, and Service packages." Is there 3 or 4 sub-packages and should we use the same naming convention within this section of the document? ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:51 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:28 PM ] |
| This is an editorial issue. Move it on ballot #12. This issue shall either be fixed or closed, but not deferred. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-242] [OMG 14326] Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=140 Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event Reported by dga...@trisotech.com, Jul 29, 2009 At row "Compensation Association" the text indicates " .... or a throw Compensate Event". Throughout the document the term "Compensation Event" is used, should this text also use the term "Compensation Event" instead? ##Proposed Resolution: Resolved (a) Table 7.2, page 28 (58 pdf), first row on page, second column: replace "Compensate Event" with "Compensation Event" (b) Section 13.2.4, Sub-Section "CompensationFlowConnector," page 371 (401 pdf), first sentence on page: "Compensate Event" with "Compensation Event" |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:50 PM ] |
| New Proposed Resolution |
[BPMNFTF-241] [OMG 14325] Page 054, Table 7-2, Gateway Control Types: Incomplete statement
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=139 Page 054, Table 7-2, Gateway Control Types: Incomplete statement Reported by dga...@trisotech.com, Jul 29, 2009 The sentence " Both Exclusive (see page 298) and Event-Based (see page 307). " is incomplete and leads to confusion while reading the text. ##Proposed Resolution: Fixed Table 7.2, row for "Gateway Control types," second column: replace "Both Exclusive (see page 298) and Event-Based (see page 307)" with "Both Exclusive (see page 298) and Event-Based (see page 307) perform exclusive decisions and merging." |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:45 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-240] [OMG 14324] Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content Reported by dga...@trisotech.com, Jul 29, 2009 The Lane depiction included in the table shows Lanes with single lines to seperate Lane name to Lane content. According to structural specification of page 316, Section 10.7, these lines should not be there. Should the figure presented excludes these lines as shown in Figure 10-119 at page 317? -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14250 (JIRA 194) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 08/Oct/09 01:18 PM ] |
| The resolution to this issue 194 is a fix for this issue |
| Comment by Stephen White [ 14/Oct/09 12:03 PM ] |
|
-------------------- Proposal ---------- 2009-10-14 ------------------------------------- Close this issue as a duplicate. The proposal for 14250 (JIRA 194) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:59 AM ] |
| Resolved (Ballot 2) |
[BPMNFTF-239] [OMG 14323] Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=137 Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation Reported by dga...@trisotech.com, Jul 29, 2009 BPMN 2.0, term is Business Process Model and Notation Same issue at page 40, section 7, 3rd paragraph. -------------------- Proposal ---------- 2009-10-19 ------------------------------------- ##Proposed Resolution: Fixed (a) on Cover Page, Title of Specification: change "Business Process Modeling Notation" to "Business Process Model and Notation" (b) In Section 1, on page 1 (31 pdf), first sentence in first paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" (c) In Section 1, on page 1 (31 pdf), second sentence in third paragraph of section: change "business process modeling notation" to "business process model and notation" (d) In Section 7, on page 13 (43 pdf), first sentence in third paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" (e) In Footers (most pages): change "Business Process Modeling Notation" to "Business Process Model and Notation" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 13/Oct/09 01:27 PM ] |
|
-------------------- Proposal ---------- 2009-10-13 -------------------------------------
(a) In Section 1, on page 1 (31 pdf), first sentence in first paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" (b) In Section 7, on page 13 (43 pdf), first sentence in third paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 19/Oct/09 10:19 AM ] |
| As per 10/19 meeting notes: Removed from Poll #2 |
| Comment by Stephen White [ 19/Oct/09 05:49 PM ] |
|
-------------------- Updated Proposal ---------- 2009-10-19 -------------------------------------
(a) on Cover Page, Title of Specification: change "Business Process Modeling Notation" to "Business Process Model and Notation" (b) In Section 1, on page 1 (31 pdf), first sentence in first paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" (c) In Section 1, on page 1 (31 pdf), second sentence in third paragraph of section: change "business process modeling notation" to "business process model and notation" (d) In Section 7, on page 13 (43 pdf), first sentence in third paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and Notation" (e) In Footers (most pages): change "Business Process Modeling Notation" to "Business Process Model and Notation" -------------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 19/Oct/09 05:50 PM ] |
| The OMG will also make this change when referring to BPMN. |
| Comment by Stephen White [ 20/Oct/09 12:20 PM ] |
|
The OMG is considering this as an Editorial Change and will post a new version of the spec with the change to "Business Process Model and Notation"
The OMG document dtc/09-08-14 will be updated and reposted on the OMG server. |
| Comment by Ivana Trickovic [ 07/Dec/09 06:00 AM ] |
| Resolved (Ballot 2) |
| Comment by Ivana Trickovic [ 03/May/10 08:38 AM ] |
|
Beta 1, Draft 2:
Not properly applied - see footnote. |
| Comment by Stephen White [ 03/May/10 07:17 PM ] |
| The remaining footers have been updated. |
[BPMNFTF-238] [OMG 14322] Page 115-120 Distinguishing Initiating and Non-Inititating Messages
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=136 Page 115-120 Distinguishing Initiating and Non-Inititating Messages Reported by dga...@trisotech.com, Jul 29, 2009 Page 115 Structural Specifcation says that Any Message that is after the first on the list of Messages for a Choreography Task or Choreography Subproces..... What about Collaboration Diagrams that do not include Choreography tasks...how do we determine Initiating and Non-Initiating -------------------- Proposal ---------- 2009-10-08 ------------------------------------- ##Proposed Resolution: Close; No Change Collaboration diagrams do not contain the information to define initiating messages. This is done in Choreography through the Choreography Activities (which is a mechanism to organize the message flow). -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 08/Oct/09 05:14 PM ] |
|
-------------------- Proposal ---------- 2009-10-08 -------------------------------------
Close; No Change Collaboration diagrams do not contain the information to define initiating messages. This is done in Choreography through the Choreography Activities (which is a mechanism to organize the message flow). -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:59 AM ] |
| Resolved (Ballot 2) |
[BPMNFTF-237] [OMG 14321] Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events On p.246 of the specification, The EventDefinition used for each start event type are explicitly listed. But in table 10-81 and 10-82 it is provided only for the None and Multiple. For consistency it should probably listed in all of them here too. ##Proposed Resolution: Close, No Change The specification text was corrected before the initial Beta 1 version was released. So we can close this issue as it needs no changes. |
[BPMNFTF-236] [OMG 14320] Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Ivana Trickovic |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
10_process-data-BPMNFTF-236-proposal.doc
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=133 Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput Reported by dga...@trisotech.com, Jul 29, 2009 In Figure 10-57, we can see that the DataOutput has a isCollection attribute as well as in Table 10-54 on page 224. The DataOutput also has itemSubjectRef attribute that is inherited from ItemAwareElement. This attribute is of type ItemDefinition and specifies the isCollection attribute. When we read the description on table 10-54 on page 224 for the isCollection attribute the following: "Defines if the DataOutput represents a collection of elements. This is a projection of the same attribute of the referenced ItemDefinition." I wonder why we need to have it defined both in DataOutput and ItemDefinition if the attribute in DataOutput is the "same". Is this denormalisation for the purpose of drawing a collection that has not be concretized by a ItemDefinition? -------------------- Proposal ---------- 2009-11-06 ------------------------------------- ##Proposed Resolution: Fixed (a) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 184 (214 pdf), Table 10.47, first row, second column: Remove second sentence in table cell, which was: This is a projection of the same attribute of the referenced ItemDefinition." (b) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 184 (214 pdf), Table 10.47, first row, second column: Add the following sentence after the first sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"." (c) in Section 10.3.1 Data Modeling, Sub-Section "Data Input," page 193 (223 pdf), Table 10.53, fifth row, second column: Remove second sentence in table cell, which was: This is a projection of the same attribute of the referenced ItemDefinition." (d) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 293 (223 pdf), Table 10.53, fifth row, second column: Add the following sentence after the first sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"." (e) in Section 10.3.1 Data Modeling, Sub-Section "Data Output," page 195 (225 pdf), Table 10.54, fifth row, second column: Remove second sentence in table cell, which was: This is a projection of the same attribute of the referenced ItemDefinition." (f) in Section 10.3.1 Data Modeling, Sub-Section "Data Output," page 295 (225 pdf), Table 10.54, fifth row, second column: Add the following sentence after the first sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"." -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 06/Nov/09 07:40 AM ] |
|
**** Proposal - 11/6/2009 ****
See: http://www.osoa.org/jira/secure/attachment/10557/10_process-data-BPMNFTF-236-proposal.doc |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-235] [OMG 14319] Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=132 Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools Reported by dga...@trisotech.com, Jul 29, 2009 The example on p. 149 shows the multi-instance marker for a black box pool. But there is no depiction of it for white box pools. ##Proposed Resolution: Duplicate The resolution of this issue in include in The Text below Figure 8.42 currently says: "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multiinstance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band of a Choreography Activity (see page 356)." Propsal: We assume that the rendering for the multi instance marker of a pool is rendered regardless if the pool is white box or black box. Chapter 13 in the current proposal does not explitily differentiate between black box and white box pools, as the only difference are the (not) contained BPMNShapes. And Table 27 in current Chapter 13 defines the depiction of the Multi Instance Marker only dependent on the ParticipantMultiplicity. |
| Comments |
| Comment by Stephen White [ 22/Mar/10 04:41 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:27 PM ] |
| Move the issue on ballot #11 and check with the DI sub-team as this could be an implementation issue (possible ambiguity). |
| Comment by Reiner Hille-Doering [ 19/Apr/10 06:05 AM ] |
|
##Proposed Resolution: Fixed
(or read it as no change based on current Spec and current Chapter 13 proposal) The Text below Figure 8.42 currently says: "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multiinstance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band of a Choreography Activity (see page 356)." Propsal: We assume that the rendering for the multi instance marker of a pool is rendered regardless if the pool is white box or black box. Chapter 13 in the current proposal does not explitily differentiate between black box and white box pools, as the only difference are the (not) contained BPMNShapes. And Table 27 in current Chapter 13 defines the depiction of the Multi Instance Marker only dependent on the ParticipantMultiplicity. Reiner. |
| Comment by Ivana Trickovic [ 19/Apr/10 06:08 AM ] |
|
Moved in balot #12 as it is part of the proposal for |
[BPMNFTF-234] [OMG 14318] Page 149, Figure 9-6 Vertical pool markers placement depiction
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| File Attachments: |
Update to Figure 9.6.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=131 Page 149, Figure 9-6 Vertical pool markers placement depiction Reported by dga...@trisotech.com, Jul 29, 2009 It would be good to have a depiction of the Multi-instance marker in the Vertical Pool layout -------------------- Proposal ----------- 2009-10-23 --------------------------------- ##Proposed Resolution: Fixed (a) Figure 9.6 will be updated to include a vertically oriented pool that has a multi-instance marker. The updated figure is shown here: http://www.osoa.org/jira/secure/attachment/10550/10550_Update+to+Figure+9.6.jpg (b) The figure caption to 9.6 will be changed to: "Pools with a Multi-Instance Participant Markers" ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 23/Oct/09 01:08 PM ] |
|
-------------------- Proposal ----------- 2009-10-23 ---------------------------------
(a) Figure 9.6 will be updated to include a vertically oriented pool that has a multi-instance marker. The attached figure shows the update. (b) The figure caption to 9.6 will be changed to: "Pools with a Multi-Instance Participant Markers" ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 06:00 AM ] |
| Resolved (Ballot 2) |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-233] [OMG 14317] Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 1 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=130 Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess Reported by dga...@trisotech.com, Jul 29, 2009 Both Adhoc and Transaction arepresented as specialized class of SubProcess, why not the same for Event SubProcess On page 187, Figure 10-27, the attribute triggeredByEvent defines if the sub-process is an event sub-process. But on page on p. 188 it is stated that an event is a specialized sub-process. If I take a look at the model is says that an ad hoc and transaction can also be event-sub-proceses. Leads to confusion regarding possible Event based transactions or Event Based Adhoc -------------------- Proposal ----------- 2009-10-27 --------------------------------- ##Proposed Resolution: Closed; No Change Event Sub-Processes should be allowed to be either Ad Hoc or Transactions. Thus, no change is recommended and this issue should be closed. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 08/Oct/09 01:06 PM ] |
| Event Sub-Processes are not a sub-class of SubProcess because they can also be a Transaction or Ad Hoc. There was no reason not to allow this. |
| Comment by Stephen White [ 27/Oct/09 06:21 PM ] |
|
-------------------- Proposal ----------- 2009-10-23 ---------------------------------
Event Sub-Processes should be allowed to be either Ad Hoc or Transactions. Thus, no change is recommended and this issue should be closed. ----------------------------------------------------------------------------------------------- |
[BPMNFTF-232] [OMG 14316] Page 063, Section 7.4 Undefined term "Flow"
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=129 Page 063, Section 7.4 Undefined term "Flow" Reported by dga...@trisotech.com, Jul 29, 2009 The first structural specification bullet of section 7.4 refers to "Flow" Where is "Flow" defined? ------------------------ New Proposed Resolution ----------- 2010-01-21 ---------------------------- ##Proposed Resolution: Fixed Section 7.4, page 34 (64 pdf), bullet on page: change "Flow objects and Flow MAY" to "BPMN elements (e.g., Flow Objects) MAY" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 21/Jan/10 06:41 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-20 ----------------------------
Section 7.4, page 34 (64 pdf), bullet on page: change "Flow objects and Flow MAY" to "BPMN elements (e.g., Flow Objects) MAY" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-231] [OMG 14315] Page 050, 061 and 417 Group text implies that only activites can be within a Group
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 050, 061 and 417 Group text implies that only activites can be within a Group Reported by dga...@trisotech.com, Jul 29, 2009 These texts of those pages specifies that a Group is a grouping of Actiovities that are within the same category. In fact a Group is tied to the Category supporting element (which is an attribute of all BPMN elements) (page 089). Thus the texts are somewhat misleading. ------------------------ New Proposed Resolution ----------- 2010-01-24 ---------------------------- ##Proposed Resolution: Fixed (a) Table 7.1, page 22 (52 pdf), fifth row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements" (b) Table 7.1, page 22 (52 pdf), fifth row on page, second column, second sentence: remove "of the Activities" (c) Table 7.2, page 32 (62 pdf), third row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements" (d) Table 7.2, page 32 (62 pdf), third row on page, second column, second sentence: remove "of the Activities" (e) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), first sentence: change "grouping of Activities" to "grouping of graphical elements" (f) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), second sentence: remove "of the Activities" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:31 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Change the first sentence of the description Table 7-1 to elements. Check other descriptions. Assign to me. |
| Comment by Stephen White [ 24/Jan/10 09:51 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-24 ----------------------------
(a) Table 7.1, page 22 (52 pdf), fifth row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements" (b) Table 7.1, page 22 (52 pdf), fifth row on page, second column, second sentence: remove "of the Activities" (c) Table 7.2, page 32 (62 pdf), third row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements" (d) Table 7.2, page 32 (62 pdf), third row on page, second column, second sentence: remove "of the Activities" (e) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), first sentence: change "grouping of Activities" to "grouping of graphical elements" (f) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), second sentence: remove "of the Activities" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-230] [OMG 14314] Page 060, Table 7-2, Merging: No depiction of implicit merge
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Figure added to Table 7-2.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=127 Page 060, Table 7-2, Merging: No depiction of implicit merge Reported by dga...@trisotech.com, Jul 29, 2009 Under the title Merging : The text talks of the possibility of an alternative representation of a merge (i.e two sequence flows entering an activity) but does not depict it or specifies it as an implicit merge ##Proposed Resolution: Fixed (a) Table 7.2, row for "Merging," third column: add a figure showing implicit merging below the current figure (see http://www.osoa.org/jira/secure/attachment/10691/Figure+added+to+Table+7-2.jpg ) (b) Table 7.2, row for "Merging," second column: add appropriate references to the two figures in column 3 |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:30 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
The table. if it describes alternative methods should be shown or remove text. And it should be consistant throughout table. Remove text. Assign to me. Review table for consistency. |
| Comment by Stephen White [ 22/Mar/10 04:38 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-229] [OMG 14313] Page 058, Table 7-2, Fork: Questionable affirmation
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 058, Table 7-2, Fork: Questionable affirmation Under the title Fork: it is stated that "uncontrolled" flow is the preferred method for most situations is a questionable affirmation. ##Proposed Resolution: Defer The FTF could not determine a proper resolution and will defer the resolution to a later RTF |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:28 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
We will make the spec non-preferential. and add an explanation as to why either method might be used. We could explain the preference that is used in spec examples |
| Comment by Ivana Trickovic [ 09/Mar/10 11:25 PM ] |
|
As per March F2F Meeting:
- Need to be addressed. - Agreed to the related specification text should be removed. |
| Comment by Stephen White [ 23/Mar/10 03:36 PM ] |
| New Proposed Resolution |
[BPMNFTF-228] [OMG 14312] Page 047, Section 7.2 Properties is presented as a Data element
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=125 Page 047, Section 7.2 Properties is presented as a Data element Reported by dga...@trisotech.com, Jul 29, 2009 Page 047, Section 7.2 Properties is presented as a Data element Not sure we understand that one yet. -------------------- Proposal ----------- 2009-10-29 --------------------------------- ##Proposed Resolution: Fixed All the elements listed in section 7.2 are graphical elements except for Properties. Thus, it should be removed from the list: (a): Section 7.2, page 20 (50 pdf), last bullet in list for Data: remove bullet item (b): Section 7.2, page 20 (50 pdf), Data section description: change "five (5) elements" to "four (4) elements" ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 30/Oct/09 12:58 AM ] |
|
-------------------- Proposal ----------- 2009-10-29 ---------------------------------
All the elements listed in section 7.2 are graphical elements except for Properties. Thus, it should be removed from the list: (a): Section 7.2, page 20 (50 pdf), last bullet in list for Data: remove bullet item (b): Section 7.2, page 20 (50 pdf), Data section description: change "five (5) elements" to "four (4) elements" ----------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 04/Nov/09 03:26 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Properties non-graphical. But will remove from list in Section 7.2. Assign to me. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-227] [OMG 14311] The attribute name is duplicated across many, many, many classes
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Unassigned |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
The attribute "name" is duplicated across many, many, many classes. Why not have a new "NamebleElement" class that specify the name or putting it in BaseElement instead of having it duplicated in many places? ##Proposed Resolution: Closed, No Change This is not an implementation issue. |
| Comments |
| Comment by Suzette Samoojh (IBM) [ 26/Jan/10 12:25 PM ] |
|
To provide some context on the motivations behind the current approach:
- A 'name' attribute is not needed everywhere. There are several classes for which a 'name' made no sense (e.g. InputOutputSpecification). Hence the reason why it wasn't put into BaseElement. - There are places where 'name' is required and others where 'name' is optional. Having multiple 'name' attributes in different classes provides a greater level of control and validation. - XSD does not support multiple inheritancy, hence we agreed that we would not introduce multiple inheritancy without a good reason. Early on it seemed like a 'NameableElement" would force multiple inheritancy. However, this was not re-assesses as the MM evolved. It could be that it will not require multiple inheritancy anymore, I don't know. I'm not stating we shouldn't re-examine the approach. Just simply providing the history, so we can make an informed assessment. |
| Comment by Conrad Bock (NIST) [ 26/Mar/10 09:57 AM ] |
|
The metamodel could have multiple inheritance, which is resolved by copy in the XSD. I thought we did this in other cases, don't we?
Regarding the resolution, it has a negative effect on the metamodel-based implementations. Each attribute is considered different in MOF, even if they have the same name. |
[BPMNFTF-226] [OMG 14310] Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEvent.
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=122 Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEvent. Reported by dga...@trisotech.com, Jul 29, 2009 On p.243, the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent Table 10-76 and CatchEvent Table 10-75. All events either inherit from ThrowEvent or CatchEvent, so why not define these attributes in the Event class instead, in order to avoid duplication? |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:25 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Similar to 219. Assign to Matthias |
| Comment by Ivana Trickovic [ 09/Mar/10 11:24 PM ] |
|
As per March F2F Meeting:
- Need to be addressed. |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:31 AM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:03 AM ] |
|
Proposed changes -- consistently name relationships/attributes, fix copy/paste errors:
----------- Table 10.75 ----------- Current: eventDefinitionRefs: EventDefinition[0..*] EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a catch Event. • If there is no EventDefinition defined, then this is considered a catch None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one EventDefinition defined, this is considered a Catch Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). eventDefinitions: EventDefinition [0..*] EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained triggers expected for a catch Event. • If there is no EventDefinition defined, then this is considered a catch None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one EventDefinition defined, this is considered a Catch Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). New: triggerRefs: EventDefinition[0..*] triggerRefs is an attribute that defines the type of reusable triggers expected for a catch Event. • If there are no triggers defined, then this is considered a catch None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one trigger defined, this is considered a Catch Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). triggers: EventDefinition [0..*] triggers is an attribute that defines the type of contained triggers expected for a catch Event. • If there are no triggers defined, then this is considered a catch None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one trigger defined, this is considered a Catch Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). ----------- Table 10.76 ----------- Current: eventDefinitionRefs: EventDefinition[0..*] EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a throw Event. • If there is no EventDefinition defined, then this is considered a throw None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one EventDefinition defined, this is considered a throw Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). eventDefinitions: EventDefinition [0..*] EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained results expected for a throw Event. • If there is no EventDefinition defined, this is considered a throw None Event and the Event will not have an Internal marker (see Figure 10-86). • If there is more than one EventDefinition defined, this is considered a throw Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). New: resultRefs: EventDefinition[0..*] resultRefs is an attribute that defines the type of reusable results expected for a throw Event. • If there are no results defined, then this is considered a throw None Event and the Event will not have an internal marker (see Figure 10-86). • If there is more than one result defined, this is considered a throw Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). results: EventDefinition [0..*] results is an attribute that defines the type of contained results expected for a throw Event. • If there are no results defined, this is considered a throw None Event and the Event will not have an Internal marker (see Figure 10-86). • If there is more than one result defined, this is considered a throw Multiple Event and the Event will have the pentagon internal marker (see Figure 10-85). |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:04 AM ] |
| newProposedResolution |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 08:28 AM ] |
|
Matthias, please see Nevertheless, we made different choices, I would be fine to rename event definition with trigger and result (part of this issue proposal), but I would keep the text changes in 218, which explain more refs vs normal. I propose we duplicate them. |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 09:10 AM ] |
|
Mariano, agree -- we should rename the attributes to match the relationship names and the text, but keep the text proposed in I'll co-reference the two items, had missed the other one because they were not co-referenced. |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 09:11 AM ] |
|
Mariano, agree -- we should rename the attributes to match the relationship names and the text, but keep the text proposed in I'll co-reference the two items, had missed the other one because they were not co-referenced. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:16 PM ] |
|
##Proposed Resolution: Duplicate
This issue is merged with |
| Comment by Suzette Samoojh (IBM) [ 19/Apr/10 05:46 PM ] |
|
I actually prefer we don't change the attribute names. See reasoning in |
[BPMNFTF-225] [OMG 14309] Page 165, Table 10-7 Required attribute cardinality explicitly defined
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=120 Page 165, Table 10-7 Required attribute cardinality explicitly defined Reported by dga...@trisotech.com, Jul 13, 2009 The cardinality of parameterRef is specified as [1]. In other cases when attributes are required the cardinality is not specified ------------------------ New Proposed Resolution ----------- 2010-01-24 ---------------------------- ##Proposed Resolution: Fixed Table 10.7, page 133 (163 pdf), first row, first column: delete "[1]" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:18 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Editorial. Assign to me. Check all attributes that have a cardinality of one |
| Comment by Stephen White [ 24/Jan/10 08:43 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-24 ----------------------------
Table 10.7, page 133 (163 pdf), first row, first column: delete "[1]" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-224] [OMG 14308] Page 331, Typo Figure references 11-3 but should be 11-4
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=119 Page 331, Typo Figure references 11-3 but should be 11-4 Reported by dga...@trisotech.com, Jul 13, 2009 The first sentence under figure 11-4 says: In figure 11-3... should be figure 11-4 -------------------- Proposal ---------- 2009-10-13 ------------------------------------- ##Proposed Resolution: Fixed In Section 11, on page 296 (326 pdf), first sentence in first paragraph after Figure 11-4: change "Figure 11-3" to "Figure 11-4" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 13/Oct/09 03:45 PM ] |
|
-------------------- Proposal ---------- 2009-10-13 -------------------------------------
In Section 11, on page 296 (326 pdf), first sentence in first paragraph after Figure 11-4: change "Figure 11-3" to "Figure 11-4" -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:59 AM ] |
| Resolved (Ballot 2) |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-223] [OMG 14307] Page 408, Section 13.2.5 Event Sub-process not included
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Diagram Interchange |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | BPMN 2.0 FTF | Assigned To: | Robert Shapiro |
| Resolution: | No Action | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Page 408, Section 13.2.5 Event Sub-process not included The Event Sub-process is not presented in the list of BPMN shapes, even if it has a distinctive aspect. Comment 1 by dga...@trisotech.com, Jul 10, 2009 All shapes are presented in this section, but the Event Sub-process is not presented in the list of BPMN shapes, even if it has a distinctive "shape". ##Proposed Resolution: Closed, no change A full new chapter covering this issue is included in the final report |
| Comments |
| Comment by Robert Shapiro [ 09/Oct/09 02:38 PM ] |
|
It appears that Section 13.2.5 should contain for EventSubProcessShape:
1: A paragraph introducing it, with a figure for collapsed and a figure for expanded. 2 a class diagram 3 a table of styles 4 a table of children The current version of section 13.2.5 contains this info for EmbeddedSubProcessShape and CalledSubProcessShape. |
| Comment by Denis Gagne [ 10/Mar/10 09:11 AM ] |
|
BPMNI F2F Meeting March 10
Chapter 13 will re-written will a simple model that will allow to render any possible shape, |
| Comment by Denis Gagne [ 11/Mar/10 02:12 AM ] |
|
BPMN DI F2F Meeting March 11
##Proposed Resolution: Closed no change Because of chapter re-write |
| Comment by Mariano Benitez (Oracle) [ 11/Mar/10 07:47 AM ] |
| New Proposed Resolution |
[BPMNFTF-220] [OMG 14306] Page 242-243 Tables 10-75 and 10-76
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Suzette Samoojh (IBM) |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue 116: Page 242-243 Tables 10-75 and 10-76 > > eported by dga...@trisotech.com, Jul 08, 2009 > Cardinality of eventDefinitions is not same that in schema of page 290 and 294 ---------------------- Proposed Resolution -------- 2010-01-11 --------------------- ##Proposed Resolution: Fixed (a) Replace the contents of Table 10.97, page 258 (288 PDF) with the following: <xsd:element name="catchEvent" type="tCatchEvent"/> <xsd:complexType name="tCatchEvent" abstract="true"> <xsd:complexContent> <xsd:extension base="tEvent"> <xsd:sequence> <xsd:element ref="dataOutput" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="dataOutputAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="outputSet" minOccurs="0" maxOccurs="1"/> <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="parallelMultiple" type="xsd:boolean" default="false"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> (b) Replace the contents of Table 10.114, page 262 (292 PDF) with the following: <xsd:element name="throwEvent" type="tThrowEvent"/> <xsd:complexType name="tThrowEvent" abstract="true"> <xsd:complexContent> <xsd:extension base="tEvent"> <xsd:sequence> <xsd:element ref="dataInput" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="dataInputAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="inputSet" minOccurs="0" maxOccurs="1"/> <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> ------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 28/Oct/09 11:33 AM ] |
| The cardinality of eventDefintion needs to be updated for CatchEvent and ThrowEvent |
| Comment by Stephen White [ 04/Nov/09 03:18 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Schema has incorrect cardinality Assign to Suzette |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:01 PM ] |
|
The actual schemas are correct. The snippets in the pdf are the only place that needs updates.
Corrected snippets (taken from the actual schema): <xsd:element name="catchEvent" type="tCatchEvent"/> <xsd:complexType name="tCatchEvent" abstract="true"> <xsd:complexContent> <xsd:extension base="tEvent"> <xsd:sequence> <xsd:element ref="dataOutput" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="dataOutputAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="outputSet" minOccurs="0" maxOccurs="1"/> <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="parallelMultiple" type="xsd:boolean" default="false"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="throwEvent" type="tThrowEvent"/> <xsd:complexType name="tThrowEvent" abstract="true"> <xsd:complexContent> <xsd:extension base="tEvent"> <xsd:sequence> <xsd:element ref="dataInput" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="dataInputAssociation" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="inputSet" minOccurs="0" maxOccurs="1"/> <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> |
| Comment by Suzette Samoojh (IBM) [ 27/Nov/09 02:03 PM ] |
| JIRA dropped the formatting in my comment above. So we should copy the snippets straight out of the schemas, rather than copying the snippets out of my comment. |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 05:10 PM ] |
|
---------PROPOSAL----------------01/11/2010------------------------------------------
Replace the snippets for tCatchEvent and tThrowEvent, in section 10.4.8 of the spec, with the content from the actual XSD. Snippets are shown above. |
| Comment by Mariano Benitez (Oracle) [ 12/Jan/10 05:49 AM ] |
|
New Proposed Resolution: Fixed
See comments above from Suzette |
[BPMNFTF-219] [OMG 14305] Table 10-76 eventDefinitionRefs and eventDefinitions descriptions
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Matthias Kloppmann (IBM) |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 243, Table 10-76 eventDefinitionRefs and eventDefinitions descriptions The two texts need to be reviewed ##Proposed Resolution: Duplicate This issue is resolved as part of issue |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:17 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Assign to Matthias The two EventDefinitions need to be differentiated |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 05:12 PM ] |
|
They're not actually identical. The eventDefinitionRefs description mentions "reusable" while the eventDefinitions mentions "contained".
The real problem is that the eventDefinitionRefs description calls these "triggers" when it should say "results". |
| Comment by Ivana Trickovic [ 09/Mar/10 11:23 PM ] |
|
As per March F2F Meeting:
- Need to be addressed. |
| Comment by Matthias Kloppmann (IBM) [ 18/Mar/10 07:32 AM ] |
| proposalScheduledForBallot11 |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:04 AM ] |
|
Fixed as part of |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:05 AM ] |
|
Close, duplicate to |
| Comment by Matthias Kloppmann (IBM) [ 12/Apr/10 04:05 AM ] |
| newProposedResolution |
[BPMNFTF-218] [OMG 14304] Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Process Orchestration |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Meera Srinivasan (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical Seems to be a copy/paste error ##Proposed Resolution: Fixed a) in Table 10.75 CatchEvent attributes and model associations 1 - For the eventDefinitionRefs Attribute, replace the following text: - "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a catch Event. " with the following text: - "References the reusable event definitions that are triggers expected for a CatchEvent. Reusable event definitions are defined as top-level elements. These event definitions can be shared by different Catch and Throw Events." 2 - For the eventDefinitions Attribute, replace the following text: - "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained results expected for a throw Event." with the following text: - "Defines the event definitions that are triggers expected for a CatchEvent. These event definitions are only valid inside the current Event." b) in Table 10.76 ThrowEvent attributes and model associations 1 - For the eventDefinitionRefs Attribute, replace the following text: - "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a throw Event." with the following text: - "References the reusable event definitions that are results expected for a ThrowEvent. Reusable event definitions are defined as top-level elements. These event definitions can be shared by different Catch and Throw Events." 2 - For the eventDefinitions Attribute, replace the following text: - "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained results expected for a throw Event." with the following text: - "Defines the event definitions that are results expected for a ThrowEvent. These event definitions are only valid inside the current Event." |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:16 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
Simple editorial issue |
| Comment by Suzette Samoojh (IBM) [ 04/Feb/10 05:09 PM ] |
| Actually, they are not quite identical. The eventDefinitionsRef specifies "reusable triggers" while the eventDefinitions specifies "contained triggers". |
| Comment by Ivana Trickovic [ 09/Mar/10 11:23 PM ] |
|
As per March F2F Meeting:
- Need to be addressed. |
| Comment by Mariano Benitez (Oracle) [ 24/Mar/10 06:59 AM ] |
|
proposalScheduledForBallot10
Meera is helping with these issues |
| Comment by Meera Srinivasan (Oracle) [ 29/Mar/10 01:43 PM ] |
|
Following places need to be updated to reflect this:
(1) In BPMN FTF Beta 1 for Version 2.0 - Aug 2009 Page 212 Table 10-75 eventDefintionsRefs and eventDefinitions descriptions (a) Original Text EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a catch Event. Replacement Text EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a catch Event. Events do not contain information regarding the event type (message, timer etc). They are the placeholders of one (or more) EventDefinitions which in turn define the source of the event. Event Definitions can be either inline (contained) or defined at top level and reused across different events in the process. The EventDefinitionRef is actually a reference to the reusable EventDefinition. (b) Original Text EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained triggers expected for a catch Event. Replaced Text EventDefinition (EventDefinition) is an attribute that defines the type of contained triggers expected for a catch Event. Events do not contain information regarding the event type (message, timer etc). They are the placeholders of one (or more) EventDefinitions which in turn define the source of the event. Event Definitions can be either inline (contained) or defined at top level and reused across different events in the process. |
| Comment by Mariano Benitez (Oracle) [ 12/Apr/10 01:26 PM ] |
|
including changes recommended in - renaming eventDefinition with trigger and results - updating diagrams and XSD snippet |
| Comment by Suzette Samoojh (IBM) [ 19/Apr/10 05:45 PM ] |
|
Actually, I'd prefer we didn't rename eventDefinition. The XSD snippets above won't work. We'd have to additionally do one of the following:
a) add new global elements "result", "resultRef", "trigger", "triggerRef" to the XSD. This is not a pattern we apply anywhere else. But then in the XML these will end up replaced with generic tags anyways: messageEventDefinition, timerEventDefinition, etc. So really, in the XML the name change won't even appear. or b) not make use of substitution groups in the XSD. The XMLs will have to use xsi:type, which is a more verbose format and not one that everyone likes. Counter-proposal: Revert the name changes. |
| Comment by Mariano Benitez (Oracle) [ 19/Apr/10 06:03 PM ] |
|
Matthias, you proposed the name change, I do not have a strong opinion either way, but Suzette seems to have a good reason to keep it this way.
If we decide to modify the proposal, I could move the issue to Ballot 12. |
| Comment by Mariano Benitez (Oracle) [ 20/Apr/10 04:42 PM ] |
| Moving to Ballot #12 so the orchestration team can decide whether to rename or not. |
[BPMNFTF-217] [OMG 14303] Depiction of diagram fragments
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 12 |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
The spec should prescribe how diagram fragments are presented. (e.g. three dots at end of continuing flows, ...) Given that BPMN has very specific structural requirements, most diagram fragments in the spec (and elsewhere) are not valid BPMN models. ##Proposed Resolution: Defer The FTF agrees that a proper definition of diagram fragment is important, but we cannot reach agreement and apply such change in this FTF. Consequently, we defer this issue to the RTF so it can define how to draw fragments and appy the definition to all relevant pictures. |
| Comments |
| Comment by Pete Rivett [ 15/Apr/10 10:46 AM ] |
|
The discussion seems to confuse diagrams and models: surely a complete and valid BPMN model could be presented through several diagrams - some of which might, for very good reasons, show only part of the model. This is, I'd argue, an important design principle and the spec should make this clear. That said, I would not object to deferring proposals for notational indicators of diagram incompleteness such as dots.
A separate point is whether it should be possible to save and interchange incomplete and technically invalid BPMN models - for example as 'work in progress'. This seems important to support for pragmatic reasons. |
[BPMNFTF-216] [OMG 14302] Page 175, Table 10-11, Spelling of Business in Attribute Name
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
> > Issue 111: Page 175, Table 10-11, Spelling of Business in Attribute Name > > Reported by dga...@trisotech.com, Jul 08, 2009 > > On p. 175 BusinesRuleTaskImplementation should be > BusinessRuleTaskImplementation and > BuisnessRuleWebService should be BusinessRuleWebService. > > Spelling of Business -------------------- Proposal ----------- 2009-10-23 --------------------------------- ##Proposed Resolution: Fixed (a) Table 10.11, Column 1, Row 1: Change "BusinesRuleTaskImplementation" to "BusinessRuleTaskImplementation" (b) Table 10.11, Column 1, Row 1: Change "BuisnessRuleWebService" to "BusinessRuleWebService" ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 23/Oct/09 01:21 PM ] |
|
-------------------- Proposal ----------- 2009-10-23 ---------------------------------
(a) Table 10.11, Column 1, Row 1: Change "BusinesRuleTaskImplementation" to "BusinessRuleTaskImplementation" (b) Table 10.11, Column 1, Row 1: Change "BuisnessRuleWebService" to "BusinessRuleWebService" ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:58 AM ] |
| Resolved (Ballot 2) |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-215] [OMG 14301] Page 370, Table 12-6, references to Event Sub-Process
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Interaction |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
In Table 12-6, many references are made to the use of different types of Start Events for Event Sub-Processes. Are Event Sub-Processes part of a Choreography diagram or are Event Sub-Processes represented by Choreography Sub-Processes in a Choreography diagram, like other Sub-processes involved in Message exchange between Participants? If Event Sub-Processes are not pat of a Choreography diagram why all these references to Event Sub-Processes in the Choreography section? If Event Sub-Processes are not part of a Choreography diagram why all these references to Event Sub-Processes in Table 12-6 ##Proposed Resolution: Fixed Table 12.6: Use of Start Events in Choreography (a) Row for Escalation: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will have to send a Message to the other Participants." (b) Row for Compensation: add the following in column 2: "No. Compensation is handled within a single Participant (anorchestration Process)." |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:45 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:25 PM ] |
| This is an editorial issue. Move it on ballot #12. This issue shall either be fixed or closed, but not deferred. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
| Comment by Stephen White [ 27/Apr/10 09:13 AM ] |
| The resolution was updated on 2010-04-27 |
| Comment by Denis Gagne [ 12/May/10 10:19 AM ] |
|
Spec-Draft3-review
The fix did not address the extra references to Event Sub-Process that are in Table 12.6 (now 11.6). This table is about Start events in choreographies and should not talk about event sub-rpocesses as per issue reported. The lines : "Not used in an Event Sub-Process" and " Can be used in an Event Sub-Process." erronuously appears in many descriptions and should not be there. Remove these sentences from row: None Message Timer Signal Multiple Conditional has the prefix [Used only for Event Sub-Processes] that should be removed |
| Comment by Ivana Trickovic [ 17/May/10 03:14 PM ] |
|
As per the meeting of May 17th: Some sentences are still there that are not needed (see the comment above). They are mentioned in the issue description. Agreed that this is an editorial change.
|
| Comment by Stephen White [ 18/May/10 12:06 AM ] |
| Done |
[BPMNFTF-214] [OMG 14300] Page 357, Figure 12-17 and 12-18 Participant names not identical
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| File Attachments: |
Update to Figure 12.17.jpg
|
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=108 Page 357, Figure 12-17 and 12-18 Participant names not identical Reported by asir...@trisotech.com, Jul 07, 2009 Figure 12-18 is stated to be a different representation of Figure 12-17. However, the Participant names are different, Participant 1 and 2 in Figure 12-17 and Participant A and B in Figure 12-18. They should be the same. -------------------- Proposal ----------- 2009-10-23 --------------------------------- ##Proposed Resolution: Fixed All figures showing generic Participant names shall use the convention of letters in the name (e.g., Participant A, Participant B) (a) Figure 12.17 will be updated with this convention. The update figure can be seen here: http://www.osoa.org/jira/secure/attachment/10551/10551_Update+to+Figure+12.17.jpg b) Figures 12.8, 12.12, 12.15, 12.21, 12.22 will also be updated .The updates to these figures are not shown here. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 23/Oct/09 02:00 PM ] |
|
The inconsistency noted in this issue appears for other figures in Chapter 12.
-------------------- Proposal ----------- 2009-10-23 --------------------------------- All figures showing generic Participant names shall use the convention of letters in the name (e.g., Participant A, Participant B) (a) Figure 12.17 will be updated with this convention. The update figure can be seen in the attached image (b) Figures 12.8, 12.12, 12.15, 12.21, 12.22 will also be updated .The updates to these figures are not shown here. ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:58 AM ] |
| Resolved (Ballot 2) |
| Comment by Ivana Trickovic [ 03/May/10 08:36 AM ] |
|
Beta 1, Draft 2
Not properly applied - see table 7.2, row "Choreography task." |
| Comment by Stephen White [ 03/May/10 07:08 PM ] |
| Change to table 7.2 figure for Choreography Task now applied. |
[BPMNFTF-213] [OMG 14299] Page 353, Figure 12-11, inapropriate caption
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=107 Page 353, Figure 12-11, inapropriate caption Reported by asir...@trisotech.com, Jul 07, 2009 The caption of Figure 12-11 is "Choreography Task". It should be "A Collaboration view of a two-way Choreography Task element". -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Duplicate Close this issue as a duplicate. The proposal for 14298 (JIRA 212) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 14/Oct/09 11:19 AM ] |
|
This issue is a duplicate of Issue 14298 (JIRA 212).
-------------------- Proposal ---------- 2009-10-14 ------------------------------------- Close this issue as a duplicate. The proposal for 14298 (JIRA 212) will resolve this issue -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:57 AM ] |
| Resolved (Ballot 2) |
[BPMNFTF-212] [OMG 14298] Page 352, Figure 12-9, inapropriate caption
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=106 Page 352, Figure 12-9, inapropriate caption Reported by asir...@trisotech.com, Jul 07, 2009 Figure 12-9 caption is "Choreography Task". It should be "A Collaboration view of Choreography Task elements". The sentence below this figure makes reference to Figure 12-7. The reference should be to Figure 12-9. -------------------- Proposal ---------- 2009-10-13 ------------------------------------- ##Proposed Resolution: Fixed (a) In Section 12.4.1, on page 317 (347 pdf), caption for Figure 12-9: change "A Choreography Task" to "A Collaboration view of a Choreography Task" (b) In Section 12.4.1, on page 317 (347 pdf), first sentence in first paragraph on page (change "see Figure 12-7" to "see Figure 12-9") (c) In Section 12.4.1, on page 318 (348 pdf), caption for Figure 12-11: change "A Choreography Task" to "A Collaboration view of a two-way Choreography Task" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 13/Oct/09 03:22 PM ] |
|
-------------------- Proposal ---------- 2009-10-13 -------------------------------------
(a) In Section 12.4.1, on page 317 (347 pdf), caption for Figure 12-9: change "A Choreography Task" to "A Collaboration view of a Choreography Task" (b) In Section 12.4.1, on page 317 (347 pdf), first sentence in first paragraph on page (change "see Figure 12-7" to "see Figure 12-9") (c) In Section 12.4.1, on page 318 (348 pdf), caption for Figure 12-11: change "A Choreography Task" to "A Collaboration view of a two-way Choreography Task" -------------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:57 AM ] |
| Resolved (Ballot 2) |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-211] [OMG 14297] Page 351, Figure 12-7 Caption of the Figure Name
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 0 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=105 Page 351, Figure 12-7 Caption of the Figure Name Figure 12-7 caption is "A Collaboration view of Choreography Task elements" is not representative of the figure. According to the text above the figure and the diagram, the caption should be: "A Collaboration view of the Participants of the Interaction". -------------------- Proposal ---------- 2009-10-14 ------------------------------------- ##Proposed Resolution: Closed; No Change Close the issue without change. The figure caption accurately represents the figure and no changes are needed. -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 14/Oct/09 11:03 AM ] |
|
The represents the Participants and the Message Flow. Thus, it shows the components of the interaction, not just the Participants.
This means that the figure caption is accurate and does not need any changes. -------------------- Proposal ---------- 2009-10-13 ------------------------------------- Close the issue without change. The figure caption accurately represents the figure and no changes are needed. -------------------------------------------------------------------------------------------------- |
[BPMNFTF-210] [OMG 14296] Page 348, Section 12.3.1, end of sentence confusing
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial, Interaction |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=104 Page 348, Section 12.3.1, end of sentence confusing Reported by asir...@trisotech.com, Jul 07, 2009 Page 348, last paragraph, first sentence reads: "In some applications it is useful to allow more Messages to be sent between Participants when a Choreography is carried out than are contained the Choreography model." The end of the sentence "... is carried out than are contained in the Choreography model." is confusing. ##Proposed Resolution: Fixed Section 12.3.1, last non-bullet paragraph in section: replace the first sentence with: "In some applications it is useful to allow additional Messages that are not part of the defined Choreography model to be sent between Participants when the Choreography is carried out." |
| Comments |
| Comment by Stephen White [ 22/Mar/10 01:30 PM ] |
| proposalScheduledForBallot11 |
[BPMNFTF-209] [OMG 14295] Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3?
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=103 Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3? Reported by asir...@trisotech.com, Jul 07, 2009 In the first and second paragraphs of page 346 a reference is made to Figure 12-4. Should it be to Figure 12-3 instead? ------------------------ New Proposed Resolution ----------- 2010-01-20 ---------------------------- ##Proposed Resolution: Fixed (a) Section 12.1, page 311 (341 pdf), first paragraph, first sentence: change "Figure 12-4" to "Figure 12-3" (b) Section 12.1, page 311 (341 pdf), second paragraph, third sentence: change "Figure 12-4" to "Figure 12-3" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Stephen White [ 21/Jan/10 12:14 AM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-20 ----------------------------
(a) Section 12.1, page 311 (341 pdf), first paragraph, first sentence: change "Figure 12-4" to "Figure 12-3" (b) Section 12.1, page 311 (341 pdf), second paragraph, third sentence: change "Figure 12-4" to "Figure 12-3" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-208] [OMG 14294] Page 345, Section 12.1 Typo, the word "Events" should be "Activities"
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=102 Page 345, Section 12.1 Typo, the word "Events" should be "Activities" Reported by asir...@trisotech.com, Jul 07, 2009 The fourth sentence of the last paragraph of page 345, reads: "For example, a Planned Order Variations Message is sent by the Supplier to the Retailer; the corresponding send and receive have been modeled using regular BPMN messaging Events." This text refers to the content of Figure 12-3 (mentionned before). No Events are shown in this Figure. The word "Events" should be replaced by "Activities". -------------------- Proposal ---------- 2009-10-02 ------------------------------------- ##Proposed Resolution: Fixed In Section 12.1, on page 310 (340 pdf), the forth sentence in the last paragraph of page: change "Events" to "Activities" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 02/Oct/09 06:01 PM ] |
|
-------------------- Proposal ---------- 2009-10-02 -------------------------------------
In Section 12.1, on page 310 (340 pdf), the forth sentence in the last paragraph of page: change "Events" to "Activities" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-207] [OMG 14293] Page 046, Section 7.2, Message not listed as a BPMN element
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=99 Page 046, Section 7.2, Message not listed as a BPMN element Reported by dga...@trisotech.com, Jul 06, 2009 The Message element is not listed in any of the categories Comment 1 by dga...@trisotech.com, Jul 10, 2009 The Message element is not listed in any of the BPMN element categories ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 25/Jan/10 12:06 PM ] |
| The previous proposal is withdrawn. We may have to come up with a new category for Message |
| Comment by Mariano Benitez (Oracle) [ 05/Feb/10 12:13 PM ] |
|
------------------------ Withdrawn Resolution ----------- 2010-01-20 ----------------------------
Section 7.2, page 20 (50 pdf), second set of bullets on page "Data": add another bullet to section with the text "Message" ------------------------------------------------------------------------------------------------------------------------ |
| Comment by Stephen White [ 22/Mar/10 01:30 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:24 PM ] |
| This is an editorial issue. Move it on ballot #12. This issue shall either be fixed or closed, but not deferred. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
[BPMNFTF-206] [OMG 14292] Page 044, Figure 7-4, The initiating party is wrongly identified in the figure
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| File Attachments: |
Update to Figure 7.4.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagné dgagne@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=98 Page 044, Figure 7-4, The initiating party is wrongly identified in the figure Reported by dga...@trisotech.com, Jul 06, 2009 The initial messages and Participant bands are greyed in error, (Reverse logic Initiating vs Return) -------------------- Proposal ----------- 2009-10-23 --------------------------------- ##Proposed Resolution: Fixed (a) Figure 7.4 will be updated to reverse the shading of the Participant Bands. The updated figure can be seen here: http://www.osoa.org/jira/secure/attachment/10552/10552_Update+to+Figure+7.4.jpg. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 23/Oct/09 02:08 PM ] |
|
-------------------- Proposal ----------- 2009-10-23 ---------------------------------
(a) Figure 7.4 will be updated to reverse the shading of the Participant Bands. The attached figure shows the update. ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 07/Dec/09 05:19 AM ] |
| Resolved (Ballot 2) |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-205] [OMG 14291] Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | No Action | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=96 Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram Reported by asir...@trisotech.com, Jul 02, 2009 The Choreography diagram shown in Figure 12-51 end with an Intermediate Event. It should be an End Event. -------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Closed; No Change The problem with Figure 12.51 was a image quality problem. The correct elements were used in the figure. The quality of Figure 12.51 has been updated by the resolution of -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 10/Nov/09 07:26 PM ] |
|
The problem with the figure was due to a degradation of the image quality during formatting of the specification source files.
Furthermore, Figure 12.51 was updated as part of the resolution of Issue 194. Thus, the figure no longer needs correction. -------------------- Proposal ---------- 2009-11-10 ------------------------------------- ##Proposed Resolution: Closed Close; No Change The problem with Figure 12.51 was a image quality problem. The correct elements were used in the figure. The quality of Figure 12.51 has been updated by the resolution of OMG Issue 1425. -------------------------------------------------------------------------------------------------- |
[BPMNFTF-204] [OMG 14288] Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3)
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=77 Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3) Reported by asir...@trisotech.com, Jul 01, 2009 Should the first two words of section 7.5.1 "Table 8.4" be replaced by "Table 7-3" ? -------------------- Proposal ---------- 2009-10-05 ------------------------------------- ##Proposed Resolution: Fixed In Section 7.5.1, on page 34 (64 pdf), first sentence in first paragraph of section: change "Table 8.4" to "Table 7.3" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 02/Oct/09 05:54 PM ] |
|
-------------------- Proposal ---------- 2009-10-02 -------------------------------------
In Section 7.5.1, on page 34 (64 pdf), first sentence in first paragraph of section: change "Table 8.5" to "Table 7.3" -------------------------------------------------------------------------------------------------- |
| Comment by Gary Brown [ 05/Oct/09 08:20 AM ] |
| Typo in proposal - should be "Table 8.4" to "Table 7.3" - as in the original problem statement. |
| Comment by Stephen White [ 05/Oct/09 01:29 PM ] |
| The proposal was updated to fix the typo. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-203] [OMG 14290] Page 115, Section 8.3.13 Copy/paste
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=81 Page 115, Section 8.3.13 Copy/paste Reported by asir...@trisotech.com, Jul 01, 2009 The second structural specification of section 8.3.13 should refer to "Message" and not "Task". -------------------- Proposal ---------- 2009-10-02 ------------------------------------- ##Proposed Resolution: Fixed In Section 8.3.13, on page 83 (113 pdf), second bullet in section: change "Task" to "Message" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 02/Oct/09 05:52 PM ] |
|
-------------------- Proposal ---------- 2009-10-02 -------------------------------------
In Section 8.3.13, on page 83 (113 pdf), second bullet in section: change "Task" to "Message" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-202] [OMG 14289] Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4)
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=78 Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4) Reported by asir...@trisotech.com, Jul 01, 2009 Should the first two words of section 7.5.2 "Table 8.5" be replaced by "Table 7-4"? -------------------- Proposal ---------- 2009-10-02 ------------------------------------- ##Proposed Resolution: Fixed In Section 7.5.2, on page 35 (65 pdf), first sentence in first paragraph of section: change "Table 8.5" to "Table 7.4" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 02/Oct/09 05:48 PM ] |
|
-------------------- Proposal ---------- 2009-10-02 -------------------------------------
In Section 7.5.2, on page 35 (65 pdf), first sentence in first paragraph of section: change "Table 8.5" to "Table 7.4" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-201] [OMG 14257] Page 042, Section 7.1.1 Reference to Figure 10-5
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=73 Page 042, Section 7.1.1 Reference to Figure 10-5 Reported by asir...@trisotech.com, Jul 01, 2009 The last paragraph, first sentence of page 42 is: "A public Process represents the interactions between a private Business Process and another Process or Participant (see Figure 10-5)." Should the reference to Figure 10-5, be replaced by Figure 7-2 presented at page 43? -------------------- Proposal ---------- 2009-09-29 ------------------------------------- ##Proposed Resolution: Fixed In Section 7.1.1, on page 15 (45 pdf), first sentence in last paragraph on page: change "Figure 10.5" to "Figure 7.2" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 09:26 PM ] |
|
-------------------- Proposal ---------- 2009-09-29 -------------------------------------
In Section 7.1.1, on page 15 (45 pdf), first sentence in last paragraph on page: change "Figure 10.5" to "Figure 7.2" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-200] [OMG 14256] Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Stephen White |
| Resolution: | Duplicate | Votes: | 0 |
| Issue Links: |
|
||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=71 Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN Reported by asir...@trisotech.com, Jul 01, 2009 Section 1, third paragraph, first sentence says: "This specification represents the amalgamation of best practices within the business modeling community to define the notation and semantics of Collaboration diagrams, Process diagrams, and Choreography diagrams." Should "Conversation diagrams", described in section 13, be added to this list? ##Proposed Resolution: Duplicate The resolution of issue 14654 will resolve this issue |
| Comments |
| Comment by Stephen White [ 20/Jan/10 11:43 PM ] |
| This issue is dependent on Issue 308. If Conversation and Collaboration are merged, then this issue could be closed with no change. |
| Comment by Stephen White [ 22/Mar/10 01:28 PM ] |
| New Proposed Resolution |
[BPMNFTF-199] [OMG 14255] Page 372, Table 12-7 Blank sections
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Why are Table sections for Escalation used in normal flow and Escalation attached to activity boundary left blank? ##Proposed Resolution: Fixed Table 12.7: Use of Intermediate Events in Choreography (a) Row for Escalation: Used in Normal Flow: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will have to send a Message to the other Participants." (b) Row for Escalation: Attached to Activity boundary: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will have to send a Message to the other Participants." |
| Comments |
| Comment by Stephen White [ 19/Mar/10 03:32 PM ] |
| New Proposed Resolution |
| Comment by Ivana Trickovic [ 04/Apr/10 11:22 PM ] |
| This is an editorial issue. Move it on ballot #12. This issue shall either be fixed or closed, but not deferred. |
| Comment by Mariano Benitez (Oracle) [ 05/Apr/10 09:51 AM ] |
| Remaining Editorial Issues are moved to Ballot 12 |
| Comment by Stephen White [ 27/Apr/10 09:10 AM ] |
| The resolution was modified on 2010-04-27 |
[BPMNFTF-198] [OMG 14254] Page 338, section 11.7 Section name versus content
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=67 Page 338, section 11.7 Section name versus content Reported by asir...@trisotech.com, Jun 29, 2009 Is the tiltle "Communication Link" or "Conversation Link"? Second term used in the text and Figure of this section. -------------------- Proposal ---------- 2009-09-29 ------------------------------------- ##Proposed Resolution: Fixed In Section 11.7, on page 302 (332 pdf), Section title: change "Communication" to "Conversation" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 09:19 PM ] |
|
-------------------- Proposal ---------- 2009-09-29 -------------------------------------
In Section 11.7, on page 302 (332 pdf), Section title: change "Communication" to "Conversation" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-197] [OMG 14253] Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=59 : Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event Reported by asir...@trisotech.com, Jun 29, 2009 The Parallel Multiple Event in Table 10-82 is the only Event without the "Catch" indicated above its diagram object. -------------------- Proposal ---------- 2009-09-29 ------------------------------------- ##Proposed Resolution: Fixed In Section 10.4.4, on page 229 (259 pdf), Table 10-82, last row on page (Parallel Multiple): add the text "Catch" above the figure in the 3rd column (as in the other rows). -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 09:15 PM ] |
|
-------------------- Proposal ---------- 2009-09-29 -------------------------------------
In Section 10.4.4, on page 229 (259 pdf), Table 10-82, last row on page (Parallel Multiple): add the text "Catch" above the figure in the 3rd column (as in the other rows). -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-196] [OMG 14252] Page 130, section 8.3.17 Copy/Paste error
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue http://code.google.com/p/bpmn2/issues/detail?id=47 : Page 130, section 8.3.17 Copy/Paste error Reported by asir...@trisotech.com, Jun 26, 2009 Second structural specification, should Task be replaced by Sequence Flow? -------------------- Proposal ---------- 2009-09-29 ------------------------------------- ##Proposed Resolution: Fixed In Section 8.3.17, on page 98 (128 pdf), second bullet on page: change "Task" to "Sequence Flow" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 09:09 PM ] |
|
-------------------- Proposal ---------- 2009-09-29 -------------------------------------
In Section 8.3.17, on page 98 (128 pdf), second bullet on page: change "Task" to "Sequence Flow" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-195] [OMG 14251] Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow"
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue <http://code.google.com/p/bpmn2/issues/detail?id=46>46: Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow" Reported by asir...@trisotech.com, Jun 26, 2009 The third strtural specification refers to Pool, should it be replaced by Message Flow? -------------------- Proposal ---------- 2009-09-29 ------------------------------------- ##Proposed Resolution: Fixed In Section 8.3.14, on page 87 (117 pdf), second bullet on page: change "Pool" to "Message Flow" -------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 09:05 PM ] |
|
-------------------- Proposal ---------- 2009-09-29 -------------------------------------
In Section 8.3.14, on page 87 (117 pdf), second bullet on page: change "Pool" to "Message Flow" -------------------------------------------------------------------------------------------------- |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-194] [OMG 14250] Page 044, Figure 7-3, Pool names not separated from content by a single line
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 2 |
| File Attachments: |
Figure 7-3 Update.jpg
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
Issue <http://code.google.com/p/bpmn2/issues/detail?id=39>39: Page 044, Figure 7-3, Pool names not separated from content by a single line Reported by asir...@trisotech.com, Jun 26, 2009 Should the Pool names be separated by a single line as stated in the structural specification in Section 9.2, page 146. -------------------- Proposal ----------- 2009-10-05 --------------------------------- ##Proposed Resolution: Fixed (a) Figure 7.3 will be updated to include the proper notation for Pools, which is to have the name of the Pool separated by a single line. The updated figure is shown here: http://www.osoa.org/jira/secure/attachment/10543/10543_Figure+7-3+Update.jpg. (b) This issue can be applied for a number of other figures in the specification. These figures are: Figure 7.2, Figure 7.5, Figure 7.6, Figure 8.14, Figure 8.30, Figure 8.31, Figure 8.36, Figure 8.37, Figure 8.41, Figure 9.5, Figure 9.6, Figure 10.5, Figure 11.1, Figure 11.2, Figure 11.3, Figure 11.4, Figure 11.11, 12.50, and Figure 12.51 The updates to these figures will not be posted. (c) Also, there are a few figures for Lanes, which do not have the single line separator, that need to be updated: The figure for Lane in Table 7.1, The figure for Lane in Table 7.2, The updates to these figures will not be posted here. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 29/Sep/09 01:13 PM ] |
|
-------------------- Proposal ----------- 2009-09-29 ---------------------------------
Figure 7.3 will be updated to include the proper notation for Pools, which is to have the name of the Pool separated by a single line. The updated figure is shown in the attached image. This issue can be applied for a number of other figures in the specification. These figures are: Figure 7.2, Figure 7.5, Figure 7.6, Figure 8.14, Figure 8.30, Figure 8.31, Figure 8.36, Figure 8.37, Figure 8.41, Figure 9.5, Figure 9.6, Figure 10.5, Figure 11.1, Figure 11.2, Figure 11.3, Figure 11.4, Figure 11.11, 12.50, and Figure 12.51 The updates to these figures will not be posted here. Also, there are a few figures for Lanes, which do not have the single line separator, that need to be updated: The figure for Lane in Table 7.1, The figure for Lane in Table 7.2, The updates to these figures will not be posted here. ----------------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 05/Oct/09 01:35 PM ] |
| The proposal was updated to add the like to the updated figure, which will not show up in the poll. But the voters can click on the link while reviewing the issue. |
| Comment by Mariano Benitez (Oracle) [ 03/May/10 05:16 PM ] |
| Verified by Ivana Trickovic on 2010/May/03 |
[BPMNFTF-193] [OMG 14249] Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
##Source: Trisotech (asirois@trisotech.com)
This is issue # 14249 Issue <http://code.google.com/p/bpmn2/issues/detail?id=37>37: Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications Reported by asir...@trisotech.com, Jun 26, 2009 Should the list presented use the diamond shape to indicate structural specifications? -------------------- Proposal ----------- 2009-10-27 --------------------------------- ##Proposed Resolution: Fixed The semantic rule statements will be shown with a diamond bullet (changed from the letter "u"). There will be no change markings to indicate these changes. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Stephen White [ 27/Oct/09 11:23 PM ] |
|
The diamond bullets are missing due to a formatting problem with the specification files in FrameMaker. This will be fixed.
-------------------- Proposal ----------- 2009-10-27 --------------------------------- The semantic rule statements will be shown with a diamond bullet (changed from the letter "u"). There will be no change markings to indicate these changes. ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 03/May/10 08:39 AM ] |
|
Beta 1, Draft 2:
I could not track the changes. Probably the resolution has been removed as part of another resolution. |
| Comment by Stephen White [ 03/May/10 07:24 PM ] |
| the resolution was applied but not marked. I add a hidden text comment listing the issue number at the first occurrence of the change (in Section 7.4) |
[BPMNFTF-192] [OMG 14248] Page 199, Figure 10-40 Types of Global Task (Text, Class Diagram and Schema do not match)
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Fixed | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Page 199, Figure 10.42 Types of Global Task (Text,Class Diagram and Schema do not match) On p. 199 of the specification The figure 10-40 Defines 4 types of global tasks: User, Manual, Script, BusinessRule. The paragraph "Types of Global Task" on p. 199 says that the list of task types is the same for globals task and standard tasks. When I look at the xml schema (Semantic.xsd) only User, Manual, Script, BusinessRule are defined. I wonder which one is true, the text or the schema? Also I wonder why the global task redefines the same attributes as standard tasks instead of referencing them. ##Proposed Resolution: Fixed The list of Global Tasks is correctly defined in the metamodel and the XSD schema, not all tasks types are allowed as global tasks. Replace the following paragraphs in "Types of Global Tasks": - This is true for both Global Tasks and standard Tasks, where the list of Task types is the same for both. - The behavior, attributes,and model associations defined in that section also apply to the types of Global Tasks. with the following text: - The types of Global Tasks are only a subset of standard Tasks types. Only GlobalUserTask, GlobalManualTask, GlobalScriptTask and GlobalBusinessRuleTask are defined in BPMN. - The behavior, attributes, and model associations defined for each type of task in that section apply to the corresponding types of Global Tasks. |
| Comments |
| Comment by Ivana Trickovic [ 09/Mar/10 07:37 AM ] |
|
As per March F2F Meeting:
- The specification text needs to be changed as not all tasks can be global tasks. - This is an editorial issue. - The following issues are related: |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
[BPMNFTF-191] [OMG 14247] Page 052, Table 7-2, Wrong figure of all event possibilities
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
Updated Event Type Figure for Table 7.2.jpg
|
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
The old list from BPMN 1.2 is presented there ##Proposed Resolution: Fixed (a) Table 7.2, page 24 (54 pdf), first row on page, third column: update figure to match BPMN 2.0 capabilities. See attached figure here: http://www.osoa.org/jira/secure/attachment/10587/10587_Updated+Event+Type+Figure+for+Table+7.2.jpg (b) Table 7.2, page 24 (54 pdf), first row on page, second column, last sentence in column: change "see page 268" to "see figure to the right" ----------------------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 11:09 AM ] |
| Component - Editorial |
| Comment by Stephen White [ 20/Jan/10 11:34 PM ] |
|
-------- New Proposed Resolution ---------- 2010-01-20 --------------------------------
(a) Table 7.2, page 24 (54 pdf), first row on page, third column: update figure to match BPMN 2.0 capabilities (see attached figure) (b) Table 7.2, page 24 (54 pdf), first row on page, second column, last sentence in column: change "see page 268" to "see figure to the right" ----------------------------------------------------------------------------------------------------------- |
[BPMNFTF-190] [OMG 14246] Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Issue <http://code.google.com/p/bpmn2/issues/detail?id=14>14: Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput Reported by <http://code.google.com/u/@VhleQVVTAxdAVgl%2B/>dga...@trisotech.com, Jun 08, 2009 On p. 227 the attributes optionalOutput and whileExecutingOuput are typed DataInput, they should be typed DataOutput. ------------------------ New Proposed Resolution ----------- 2010-01-20 ---------------------------- ##Proposed Resolution: Fixed (a) Table 10.56, page 199 (229 pdf), row 3, column 1: change "DataInput" to "DataOutput" (b) Table 10.56, page 199 (229 pdf), row 4, column 1: change "DataInput" to "DataOutput" ------------------------------------------------------------------------------------------------------------------------ |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 11:07 AM ] |
| Component - Editorial |
| Comment by Stephen White [ 20/Jan/10 09:24 PM ] |
|
------------------------ New Proposed Resolution ----------- 2010-01-20 ----------------------------
(a) Table 10.56, page 199 (229 pdf), row 3, column 1: change "DataInput" to "DataOutput" (b) Table 10.56, page 199 (229 pdf), row 4, column 1: change "DataInput" to "DataOutput" ------------------------------------------------------------------------------------------------------------------------ |
[BPMNFTF-189] [OMG 14245] Page 199 class model for the global tasks
|
|
| Status: | Closed |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | Ballot 10 |
| Fix Version/s: | Ballot 10 |
| Type: | Bug | Priority: | Major |
| Reporter: | Denis Gagne | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Won't Fix | Votes: | 0 |
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Page 199 class model for the global tasks On p.199, (Section 10.2.7 Global Tasks) there is a class model for the global tasks, but there no table that explains the attributes that are displayed on the diagram like the other classes in the document. ##Proposed Resolution: Close, No Change In order not to duplicate the information, a reference to the page where tasks are defined is included in that section. So there is no need to add a table describing attributes and behaviour, since they are similar to standard tasks. Nevertheless, there is a single attribute in Global Task that must be described: performers, which is covered by issue 14732 |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 11:06 AM ] |
| Component - Editorial |
| Comment by Ivana Trickovic [ 09/Mar/10 07:44 AM ] |
|
As per March F2F Meeting:
- This is an editorial issue - This issue is related to |
| Comment by Mariano Benitez (Oracle) [ 15/Mar/10 05:57 PM ] |
| proposalScheduledForBallot10 |
[BPMNFTF-188] [OMG 14244] The case of some attribute name is not consistent.
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | Editorial |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
Issue <http://code.google.com/p/bpmn2/issues/detail?id=3>3: The case of some attribute name is not consistent. Reported by dga...@trisotech.com, Jun 08, 2009 It seems that lower case is the standard, but some attributes like ReceiveTask.Instanciate, UserTask.Imlementation for example, but there are other attributes as well. The same comment applies to type name string vs String, Boolean vs Boolean, etc... Comment 1 by hudoneric, Jun 09, 2009 The case of the gatewayDirection on p.111 is lower case. The values of other enumerations in the document are capitalized. Comment 2 by hudoneric, Jun 10, 2009 Same thing for multi-instance behavior on p.203. Comment 3 by hudoneric, Jun 10, 2009 The case of the enumeration UserTaskImplementation is not the same in the specification (p. 179) and the schema (p. 181). Comment 4 by hudoneric, Jun 10, 2009 The case of the methodon p.192is lower case. The values of other enumerations in the document are capitalized. -------------------- Proposal ----------- 2020-01-05 --------------------------------- ##Proposed Resolution: Fixed (a) Table 10.10, page 140 (170 pdf), second row, first column: Change "Instantiate:" to "instantiate:" (b) Table 10.13, page 146 (176 pdf), first row, first column: Change "Implementation:" to "implementation:" (c) Table 10.2, page 135 (165 pdf), first row, first column: Change "String:" to "string:" (d) Table 8.47, page 80 (110 pdf), first row, first column: Change "unspecified | converging | diverging |mixed" to "Unspecified | Converging | Diverging |Mixed" (e) Table 8.47, page 80 (110 pdf), first row, second column: Change "unspecified" to "Unspecified", "converging" to "Converging ", "diverging" to "Diverging", and "mixed" to "Mixed" (f) Figure 8.25, page 79 (109 pdf): Capitalize the items within the GatewayDirection enumeration. (g) Table 10.26, page 172 (202 pdf), second row on page, first column: Change "none | one | all | complex" to "None | One | All | Complex" (h) Table 10.26, page 172 (202 pdf), second row on page, second column: Change "none" to "None", "one" to "One", "all" to "All ", and "complex" to "Complex" (i) Table 10.13, page 146 (176 pdf), first row, first column: Change all types of UserTaskImplementation from uppercase to lowercase Note that some of the changes to the case of key words such as string, boolean, and integer or the case of enumeration values were not documented. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 11:03 AM ] |
| Component - Editorial |
| Comment by Stephen White [ 05/Jan/10 06:13 PM ] |
|
-------------------- Proposal ----------- 2020-01-05 ---------------------------------
(a) Table 10.10, page 140 (170 pdf), second row, first column: Change "Instantiate:" to "instantiate:" (b) Table 10.13, page 146 (176 pdf), first row, first column: Change "Implementation:" to "implementation:" (c) Table 10.2, page 135 (165 pdf), first row, first column: Change "String:" to "string:" (d) Table 8.47, page 80 (110 pdf), first row, first column: Change "unspecified | converging | diverging |mixed" to "Unspecified | Converging | Diverging |Mixed" (e) Table 8.47, page 80 (110 pdf), first row, second column: Change "unspecified" to "Unspecified", "converging" to "Converging ", "diverging" to "Diverging", and "mixed" to "Mixed" (f) Figure 8.25, page 79 (109 pdf): Capitalize the items within the GatewayDirection enumeration. (g) Table 10.26, page 172 (202 pdf), second row on page, first column: Change "none | one | all | complex" to "None | One | All | Complex" (h) Table 10.26, page 172 (202 pdf), second row on page, second column: Change "none" to "None", "one" to "One", "all" to "All ", and "complex" to "Complex" (i) Table 10.13, page 146 (176 pdf), first row, first column: Change all types of UserTaskImplementation from uppercase to lowercase Note that some of the changes to the case of key words such as string, boolean, and integer or the case of enumeration values were not documented. ----------------------------------------------------------------------------------------------- |
| Comment by Ivana Trickovic [ 03/May/10 08:44 AM ] |
|
Beta 1, Draft 2:
Not correctly applied: should use upper cases in table 10.29 (second column). |
| Comment by Stephen White [ 03/May/10 07:48 PM ] |
| Changes to table 10.29 now correctly applied |
| Comment by Falko Menge [ 09/Jun/10 06:14 AM ] |
|
spec-May24-review
Table 10.19 still contains attribute values 'diverging' and 'converging' in lowercase. Proposal: Replace 'diverging' with 'Diverging' and 'converging' with 'Converging' in Table 10.19 for the model to be schema-valid. |
[BPMNFTF-187] [OMG 14243] Many editorial issues
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 5 |
| Type: | Bug | Priority: | Trivial |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
##Source: Trisotech (Denis Gagne dgagne@trisotech.com)
BPMN 2 FTF typos Page 79, Table 8-8 Typo extensionAttributeDefinitions is typed ExtensionDefinition On p.79, Table 8-8 the attribute extensionAttributeDefinitions is typed ExtensionDefinition, it should be typed ExtensionAttributeDefinition. ========================================================================== Page 141, Table 8-81 Typo in type definition "s" added callableElements should be of type CallableElement and not CallableElements ================================================================== Page 283, Figure 10-90 Typo "CancelEventDefinition" should be reploaced by "TerminateEventDefinition" On p. 283 of the specification, we can read CancelEventDefinition element inherits... Since a TerminateEventDefinition exists, I assume that this is what should go there. ========================================================================= Page 307, section 10.5.6 Copy/paste Typo "Start Event" should be "Event Gateway" In second structural specification Start Event should be replaced by Event Gateway. ================================================================= Page 316, section 10.7 Copy/Paste Typo "Pool" should be replaced by "Lane" In second structural specificatio Pool should be replaced by Lane ========================================================================= Page 049, Table 7-1, Typo word "is' extra For the element "Pool" the second sentence of the descriptive text is: "It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations." The word "is" at the beginning of the sentence should be deleted. ========================================================================= Page 052, Table 7-2, Typo missing "a" before Process For element "Activity" the first sentence is: "An Activity is a generic term for work that company performs (see page 159) in Process." The word "a" shoud be added before the word "process". =================================================================== Page 053, Table 7-2, Typo missing "or" in sentence For element "Choreography Task", the last sentence of the descption is:"There are two (2) more Participant Bands and one Task Name Band." The word "or" shoud be added after the "two (2)". - For element "Choreography Task", the last sentence of the descption is:"There are two (2) more Participant Bands and one Task Name Band." The word "or" shoud be added after the "two (2)". Same apply to last sentence of page 351. Also apply to Page 356, Section 12.4.2, last sentence of second paragraph. ==================================================================== Page 087, Typo "a" should be "are" In sub-section "Common Artifact Definitions", the sentence reads:"The following sections provide definitions that a common to all Artifacts." "That a common" should be replaced by "that are common". ===================================================================== Page 124, Section 8.3.15, Typo Missing "are" in frist sentence The first sentence of Section 8.3.15 is: "A Participant represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that Participants in a collaboration." The word "are" should be added to read " ..... that are Participants in a collaboration." ===================================================================== Page 145, Section 9, Typo missing "in" Page 145, last paragraph, first sentence reads: "In some applications it is useful to allow more Messages to be sent between Participants when a Collaboration is carried out than are contained the Collaboration model." The word "in" should be added, for the sentence later part to read: " .... are contained in the Collaboration model." ====================================================================== Page 146, Section 9.1 Typo word "main" should be "may" Section 9.1, second paragraph, first sentence reads:"A Pool may be empty, a "black box," or main show a Process within." The word "main" should be replaced by "may". ====================================================================== Page 163, Section 10.2, Typo "An" should replace "A" In page 163, the second structural specification (just before section 10.2.1) reads: "A Activity MAY be a source for Message Flow; it can have zero or more outgoing Message Flow." The first word of the sentence "A" should be replaced by the word "An". ====================================================================== Page 188, Section "Event Sub-Process", Typo missing "is" The frst sentence after the sub-section title "Event Sub-Process" reads: "An Event Sub-Process is a specialized Sub-Process that used within a Process (or Sub-Process)." The word "is" should be added for the sentence to read: "An Event Sub-Process is a specialized Sub-Process that is used within a Process (or Sub-Process)." ==================================================================== Page 188, sub-section "Event Sub-Process" Typo The last structural specification of page 188 reads: "The use of text, color, size, and lines for a Sub-Process MUST follow the rules defined in Section "Use of Text, Color, Size, and Lines in a Diagram" on page 63 with the exception that:" The words " a Sub-Process MUST" should be replaced by "an Event Sub-Process MUST". ==================================================================== Page 231, sub-section "DataInputAssociation", Typo "an" vs "a" The first sentence of page 231 reads: "The DataInputAssociation can be used to associate a item-aware element with a DataInput contained in an Activity." The word "a" before "item-aware" should be replaced by the word "an". =================================================================== Page 308, Section 10.5.6, Typo Replace "follow" by "following" The fifth structural specification in page 308, reads: "Only the following Intermediate Event triggers are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the follow Intermediate Event triggers are not valid: Error, Cancel, Compensation, and Link." The word "follow" in the second sentence of the specification should be replaced by "following". ================================================================= Page 320, Section 10.8, Typo missing word "in" Section 10.8, second paragraph, first sentence reads: "In some applications it is useful to allow more Activities and Events to occur when a Process is executed or performed than are contained the Process model." The word "in" should be added for the end of the sentence to read " .... than are contained in the Process model." ================================================================ Page 343, Section 12, Typo Two verbs used instead of one The sentence above Figure 12-2 reads: "Figure 12-1 shows displays the metamodel ...". One of the two verbs, "shows" or "displays" should be deleted. =============================================================== Page 367, Section 12.4.6, Typo, word "will" to be deleted The second sentence of page 367 reads: "The Choreography Task that has two Messages will is reflected by three Process Tasks." The word "will" should be deleted. ============================================================== Page 164, Table 10-5, Typo "s" added to Type There is also a typo on p. 164. resourceParameterBindings should be of type ResourceParameterBinding and not ResourceParameterBindings. ============================================================== Page 361 Section 12.4.3 Typo "collpased" instead of "collapsed" On page Page 361 Section 12.4.3 "collpased" should be read "collapsed". The text is located on the third bullet of the section 12.4.3. ============================================================= Page 044, Figure 7-4, Page 345 Figure 12-2 and Page 394 Figure 12-50 Typo in the figure The last Choreography activity in Figure 7-4, Figure 12-2 and Figure 12-50 should be labeled "Handle Medecine". ==================================================================== Page 264 Table 10-85 Typo in table caption "cancel Activity" should be "cancelActivity" ======================================================================== -------------------- Proposal ----------- 2009-12-21 --------------------------------- ##Proposed Resolution: Fixed (a) Table 8.8, page 48 (78 pdf), second row, first column: Change "ExtensionDefinition" to "ExtensionAttributeDefinition" (b) Table 8.80, page 108 (138 pdf), third row, first column: Change "CallableElements" to "CallableElement" (c) Section 10.4.4 Event Definitions, Sub-Section "Terminate Event," page 251 (281 pdf), first sentence on page: Change "CancelEventDefintion" to "TerminateEventDefinition" (d) Section 10.5.6 Event Gateway, page 274 (304 pdf), second bullet on page: Change "a Start Event" to "an Event Gateway" (e) Section 10.7 Lanes, page 282 (312 pdf), second bullet on page: Change "Pool" to "Lane" three times in bullet (f) Table 7.1, page 22 (52 pdf), first row on page, second column: Change "It is also acts" to "It also acts" (g) Table 7.2, page 33 (63 pdf), second row on page, second column: Change "It is also acts" to "It also acts" (h) Table 7.1, page 21 (51 pdf), second row on page, second column: Change "in Process" to "in a Process" (i) Table 7.2, page 24 (54 pdf), second row on page, second column: Change "in Process" to "in a Process" (j) Table 7.2, page 24 (54 pdf), last row on page, second paragraph: change "two (2) more" to "two (2) or more" (k) Section 12.4.1 Choreography Task, page 316 (346 pdf), second paragraph on page, last sentence in paragraph: change "two (2) more" to "two (2) or more" (l) Section 12.4.2 Choreography Sub-Process, page 321 (351 pdf), first paragraph in section, last sentence in paragraph: change "two (2) more" to "two (2) or more" (m) Section 13.2.5 BPMN Shapes, Sub-Section "ChoreographyActivityShape," page 379 (409 pdf), first paragraph in section, last sentence in paragraph: change "two (2) more" to "two (2) or more" (n) Section 8.3.1 Artifacts, Sub-Section "Common Artifact Definitions," page 56 (86 pdf), first paragraph in section, first sentence: change "that a common" to "that are common" (o) Section 8.3.15 Participants, page 91 (121 pdf), first sentence in section: change "that Participants" to "that are Participants" (p) Section 9 Collaboration, page 113 (133 pdf), last paragraph on page, first sentence: change "contained the" to "contained in the" (q) Section 9.1 Basic Collaboration Concepts, page 114 (144 pdf), second paragraph in section, first sentence: change "or main show" to "or may show" (r) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), first sentence in section: change "that used within" to "that is used within" (s) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), sixth bullet in section: change "for a Sub-Process" to "for an Event Sub-Process" (t) Section 10.3.1 Data Modeling, Sub-Section "DataInputAssociation," page 202 (232 pdf), first sentence in section: change "a item-aware" to "an item-aware" (U) Section 10.8 Process Instances, Unmodeled Activities, and Public Processes, page 286 (316 pdf), second paragraph in section, first sentence: change "contained the Process" to "contained in the Process" (v) Section 12 Choreography, page 318 (338 pdf), paragraph above Figure 12.1, first sentence: change "Figure 12.1 shows displays" to "Figure 12.1 displays" (w) Section 12.4.6 The Sequencing of Activities, page 331 (361 pdf), firt paragraph on page, second sentence: change "Messages will is" to "Messages is" (x) Table 10.5, page 132 (162 pdf), third row, first column: change "ResourceParameterBindings [0..*]" to "ResourceParameterBinding [0..*]" (y) Section 12.4.3 Call Choreography Activity, page 326 (356 pdf), third bullet on page: change "collpased" to "Collapsed" (z) Figure 7.4, Figure 12.2, and Figure 12.5: change the Choreography Task label for the last task in the diagram from "Handle Symptoms" to "Handle Medicine" (aa) Table 10.85, page 234 (264 pdf), Table Caption: change "cancel Activity" to "cancelActivity" Note: a typo reported for page 131 (163 pdf as reported) was no longer valid. Note: a typo reported for page 275 (308 pdf as reported) was no longer valid. ----------------------------------------------------------------------------------------------- |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 10:44 AM ] |
| Component - Editorial |
| Comment by Stephen White [ 21/Dec/09 09:21 PM ] |
|
-------------------- Proposal ----------- 2009-12-21 ---------------------------------
(a) Table 8.8, page 48 (78 pdf), second row, first column: Change "ExtensionDefinition" to "ExtensionAttributeDefinition" (b) Table 8.80, page 108 (138 pdf), third row, first column: Change "CallableElements" to "CallableElement" (c) Section 10.4.4 Event Definitions, Sub-Section "Terminate Event," page 251 (281 pdf), first sentence on page: Change "CancelEventDefintion" to "TerminateEventDefinition" (d) Section 10.5.6 Event Gateway, page 274 (304 pdf), second bullet on page: Change "a Start Event" to "an Event Gateway" (e) Section 10.7 Lanes, page 282 (312 pdf), second bullet on page: Change "Pool" to "Lane" three times in bullet (f) Table 7.1, page 22 (52 pdf), first row on page, second column: Change "It is also acts" to "It also acts" (g) Table 7.2, page 33 (63 pdf), second row on page, second column: Change "It is also acts" to "It also acts" (h) Table 7.1, page 21 (51 pdf), second row on page, second column: Change "in Process" to "in a Process" (i) Table 7.2, page 24 (54 pdf), second row on page, second column: Change "in Process" to "in a Process" (j) Table 7.2, page 24 (54 pdf), last row on page, second paragraph: change "two (2) more" to "two (2) or more" (k) Section 12.4.1 Choreography Task, page 316 (346 pdf), second paragraph on page, last sentence in paragraph: change "two (2) more" to "two (2) or more" (l) Section 12.4.2 Choreography Sub-Process, page 321 (351 pdf), first paragraph in section, last sentence in paragraph: change "two (2) more" to "two (2) or more" (m) Section 13.2.5 BPMN Shapes, Sub-Section "ChoreographyActivityShape," page 379 (409 pdf), first paragraph in section, last sentence in paragraph: change "two (2) more" to "two (2) or more" (n) Section 8.3.1 Artifacts, Sub-Section "Common Artifact Definitions," page 56 (86 pdf), first paragraph in section, first sentence: change "that a common" to "that are common" (o) Section 8.3.15 Participants, page 91 (121 pdf), first sentence in section: change "that Participants" to "that are Participants" (p) Section 9 Collaboration, page 113 (133 pdf), last paragraph on page, first sentence: change "contained the" to "contained in the" (q) Section 9.1 Basic Collaboration Concepts, page 114 (144 pdf), second paragraph in section, first sentence: change "or main show" to "or may show" (r) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), first sentence in section: change "that used within" to "that is used within" (s) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), sixth bullet in section: change "for a Sub-Process" to "for an Event Sub-Process" (t) Section 10.3.1 Data Modeling, Sub-Section "DataInputAssociation," page 202 (232 pdf), first sentence in section: change "a item-aware" to "an item-aware" (U) Section 10.8 Process Instances, Unmodeled Activities, and Public Processes, page 286 (316 pdf), second paragraph in section, first sentence: change "contained the Process" to "contained in the Process" (v) Section 12 Choreography, page 318 (338 pdf), paragraph above Figure 12.1, first sentence: change "Figure 12.1 shows displays" to "Figure 12.1 displays" (w) Section 12.4.6 The Sequencing of Activities, page 331 (361 pdf), firt paragraph on page, second sentence: change "Messages will is" to "Messages is" (x) Table 10.5, page 132 (162 pdf), third row, first column: change "ResourceParameterBindings [0..*]" to "ResourceParameterBinding [0..*]" (y) Section 12.4.3 Call Choreography Activity, page 326 (356 pdf), third bullet on page: change "collpased" to "Collapsed" (z) Figure 7.4, Figure 12.2, and Figure 12.5: change the Choreography Task label for the last task in the diagram from "Handle Symptoms" to "Handle Medicine" (aa) Table 10.85, page 234 (264 pdf), Table Caption: change "cancel Activity" to "cancelActivity" Note: a typo reported for page 131 (163 pdf as reported) was no longer valid. Note: a typo reported for page 275 (308 pdf as reported) was no longer valid. ----------------------------------------------------------------------------------------------- |
| Comment by Denis Gagne [ 12/May/10 09:51 AM ] |
|
Spec-Draft3-review
Althought the fix of item(k) and item (j) were properly applied. There can now only be two participant bands on a Choreography task and thus these two locations nedd to reflect this. |
| Comment by Ivana Trickovic [ 17/May/10 03:10 PM ] |
|
As per the meeting of May 17th: (k) and (j) to be corrected according another issue resolution (e.g. |
| Comment by Stephen White [ 17/May/10 11:46 PM ] |
| Done |
[BPMNFTF-186] [OMG 14242] Concept definition for Business Process
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Mariano Benitez (Oracle) |
| Resolution: | Unresolved | Votes: | 0 |
| File Attachments: |
BPMN2-Issue186-BusinessProcess.doc
|
| Description |
|
##Source: PNA University (Jean-Paul Koster jean.paul.koster@pna-university.nl)
Specification: BPMN Section: Annex C - Glossary FormalNumber: bmi/2009-06-05 Version: V0.9.15 RevisionDate: 06/15/2009 Page: 499 Title: Concept definition for Business Process Nature: Clarification Severity: Significant Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition: Business Process: A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD. ##Proposed Resolution: Defer This issue is a clarification/refinement of some basic and general concepts that do not have a direct impact on any implementation. The FTF decides to defer this issue to the RTF to properly discuss and agree on this general term |
| Comments |
| Comment by Ivana Trickovic [ 16/Sep/09 10:40 AM ] |
| Component - General |
| Comment by John Bulles [ 22/Sep/09 08:58 AM ] |
| My suggestion would be to adopt this concept definition and change it in the glossary of the spec. |
| Comment by John Hall [ 30/Sep/09 08:12 AM ] |
|
I did not see "TBD" in the glossary for the Beta spec of BPMN 2.0 (09-08-14.pdf). There is a definition, one of a circle of three that have persisted since BPMN 1.0:
Business Process: A Business Process is displayed within a Business Process Diagram (BPD). A Business Process contains one or more Processes. Process: A Process is any activity performed within a company or organization. In BPMN a Process is depicted as a network of Flow Objects, which are a set of other activities and the controls that sequence them. Activity: An activity is a generic term for work that a company or organization performs via business processes. An activity can be atomic or non-atomic (compound). The types of activities that are a part of a Process Model are: Process, Sub-Process, and Task. It would be helpful to remove the circularity ("A business process [is something that] contains one or more processes, each of which is work performed by a company or organization via business processes"), while retaining: 1 The notion of purposeful work 2 The relationships between the concepts "Business Process", "Process" and "Activity". In the definition proposed, I think that it is too restrictive to require that every business process: 1 Must involve cooperation 2 Must produce a product or deliver a service to a customer |
| Comment by John Bulles [ 04/Oct/09 02:30 PM ] |
|
I propose the following definition for business process in the glossary:
Business Process: A Business Process is a person or system, or a cooperation between several people and/or systems, each performing a particular role and possible other entities such as departments within a company or organizations, in order to produce a product or to deliver a service to a customer, being any person or organisation requesting the product or service produced by the business process. |
| Comment by John Hall [ 05/Oct/09 08:51 AM ] |
|
I have several concerns about the latest proposed definition:
1 A person is not a business process 2 'System' is not defined in the glossary. Here, does it mean IT system or business system or both? 3 How are "possible other entities such as departments within a company or organizations" involved with the business process? Are they 'customers' (see next point) or does the business process interact with business processes in which they play roles? 4 'Customer' is not defined in the glossary. Does it mean 'customer' in the conventional sense, of a person or organization outside a business that buys products and services from the business? With this meaning, many business processes do not produce a product or to deliver a service to a customer. Or does it mean the 'customer role' - of anything inside or outside the business that expects something to be delivered by a business process? If this meaning is intended, we should say so (and we would probably need a different term for customer as an external person or organization outside a business that buys its products and services) 5 The part of the existing definition that relates 'business process' to 'process' and (indirectly) to 'activity', is omitted I have posted a Word document 'BPMN2-Issue186-BusinessProcess.doc' that suggests an SBVR-based approach for developing a definition for business process |
| Comment by John Hall [ 05/Oct/09 08:59 AM ] |
| Accompanies posting by John Hall on 5 October 2009 |
[BPMNFTF-185] [OMG 14240] Conformance Classes are overley Broad
|
|
| Status: | Applied |
| Project: | OMG BPMN FTF |
| Component/s: | General |
| Affects Version/s: | Ballot 11 |
| Fix Version/s: | Ballot 11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Robert Shapiro |
| Resolution: | Fixed | Votes: | 0 |
| File Attachments: |
ANALYTIC example.zip
Conformance DESCRIPTIVE_ANALYTIC_EXECUTABLE proposal for BPMN2 Spec.doc
Conformance DESCRIPTIVE_ANALYTIC_EXECUTABLE proposal for BPMN2 Spec.doc
Conformance DESCRIPTIVE_ANALYTIC_EXECUTABLE proposal for BPMN2 Spec.doc
Conformance DESCRIPTIVE_ANALYTIC_EXECUTABLE proposal for BPMN2 Spec.doc
Conformance+DESCRIPTIVE_ANALYTIC_EXECUTABLE+proposal+for+BPMN2+Spec.doc
ConformanceClassesProposal_Attributes.xls
Personas and Conformance Classes.doc
Standard Process.jpg
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
##Source: Fujitsu (Tom Rutt, tom@coastin.com)
2.1.1 process modeling conformance: what could a platform which supports all the diagrams except for conversation diagrams claim conformance to? This might be important for migration from BPMN 1implementations. Can it claim some form of "partial compliance? The FTF should define more granular conformance Classes, to ease migration from BPMN 1.2 implementations. ##Proposed Resolution: Fixed Please read the document attached to the link below for a proposal description. We will update the resolution description with more adequate content before we open the ballot. http://www.osoa.org/jira/secure/attachment/10709/Conformance+DESCRIPTIVE_ANALYTIC_EXECUTABLE+proposal+for+BPMN2+Spec.doc Note: the FTF report will include the full list of changes, but for the vote we are just including a link to the content, as an exception. After the ballot closes we will copy the content of the document into the issue description so it is included in the report. |
| Comments |
| Comment by Mariano Benitez (Oracle) [ 16/Sep/09 10:31 AM ] |
| the initial assumptions of the F2F is that we should work on this issue. |
| Comment by Mariano Benitez (Oracle) [ 16/Sep/09 10:36 AM ] |
| the assignee will be Tom Rutt when he's account is created. |
| Comment by Ivana Trickovic [ 19/Oct/09 05:18 AM ] |
| As per Oct 12th meeting minutes: Robert S. will take ownership of this issue. |
| Comment by Stephen White [ 09/Dec/09 04:26 PM ] |
|
--------------- Discussion during F2F/Call on 2009-12-09 ----------------------------------
We reviewed the update spread sheet from Robert http://www.omgwiki.org/bpmn2.0-ftf/doku.php?id=public:presentations_examples Now includes DoDAF level. There is a total of four levels (including full) • Simple • Descriptive • Analytic (DoDAF). This is the subset being used by UPDM. • Full How do we tag the levels in the spec (including non-graphical elements and properties)? Robert still needs to look at the non-graphical elements/properties that should be added for each level. Collaboration is used for a subset, but Conversation is not. Action: Robert will draft an modification for the Section 2 (Conformance) of the Spec. What is the general criteria for the levels-the use cases. The personas are documented Is this a normative requirement? Are we just formalizing methodologies? What about interchange? A long discussion ensued: Do all the tools, with their level of compliance, have to import/export all levels? What does a tool do with information that the tool doesn't support? Convert the information to simpler versions? For example, what does a simple level tool do with a model that has a Complex Gateway? A User Task can be shown as a simple Task. But this doesn't work for all situations--like the Complex Gateway--because the behavior would change. We might add a attribute to Process to state the level of compliance for that model. It would be just a statement of intent, subject to validation. Should we support round-tripping between tools of different levels? E.g., from Simple to Full back to Simple. The Simple tools can save the unsupported information and then export the information back out. There was a concern that import/export between tools should not result in any loss of information. This would work against interoperability. This means that all tools, regardless of conformance level, must support (import/export) the entire BPMN schema. The conformance then is only referring to the editing environment, not the exchange format. The tools would have to decide how to deal with imported information that is unsupported in their modeling environment. They could hide it, convert it, make it read only, etc. We probably won't specify that in the spec. There is still some disagreement about whether a tool MUST save unsupported information--or if it should be SHOULD save. |
| Comment by Suzette Samoojh (IBM) [ 11/Jan/10 12:24 PM ] |
|
Robert,
Would you be able to fill out the spreadsheet to include the Full set? Beyond calling out what is in each level, I think it's important to validate what has been omitted from each level. That information is hard to glean from the current spreadsheet. A full enumeration of all constructs will make the omissions explicit. Thanks. |
| Comment by Robert Shapiro [ 14/Feb/10 08:25 PM ] |
|
I have added a document to the wiki which is a proposal for changes to section 2 of the specification See Conformance Sub-Class Draft for BPMN2.0 specification.
I would also like to include some diagrams illustrating each sub-class. Where should these go in the document?? |
| Comment by Robert Shapiro [ 01/Mar/10 12:31 PM ] |
| After the March 1 FTF I have uploaded a new version of the proposal which corrects the table for the DODAF conformance subclass and also replaces the name DODAF with the name ANALYTIC. Please comment on any further issues prior to the March 15th FTF so that I can make any further required changes. |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 06:16 PM ] |
|
Robert,
I took a quick look at the XPDL 2.1 spec, to see how it describes conformance to the different subclasses. I was motivated by my assumption that XPDL has been doing this for some time, and so would have proven what is and is not doable. We could then learn from those experiences. But XPDL describes conformance as: "A modeling tool asserting compliance to one of these classes means that the tool can import and understand all parts of a serialized BPMN instance conformant to the class." Which I interpret to mean, for example, that a tool which claims conformance to 'Simple' has to be able to import and understand only the constructs in the Simple class. It is not required to import anything beyond the Simple class. Nor is it required to write out anything beyond the Simple class. Is my interpretation correct? If so, seems like we're trying something a lot more sophisticated with the BPMN conformance. Why is that? I'm worried about the criteria we've defined for compliance in BPMN. Going from less to more (e.g. Simple -> Descriptive; Descriptive -> Analytic) is easy and straight forward. My experience is that the reverse is difficult, non-trivial, and loss-of-information is a realistic possibility. So the third bullet in your proposed conformance criteria is particularly worrisome. I'm sort of okay with requiring that all tools support import of the entire standard. But the idea of a simple tool importing a complex model, maintaining the original complex model while abstracting the details out to allow edits at the simple level, and then being able to spit back out a cohesive complex model with all of the gorpy complex details. Wow. That's a lot of implementation complexity and overhead for a simple tool to be forced to do. I'm not even sure it's doable. It would have to be proven and tested. Has that happened? Is there precedence for this that would demonstrate this is doable? |
| Comment by Suzette Samoojh (IBM) [ 09/Mar/10 06:21 PM ] |
|
Some comments/questions as specifics within the proposal:
- Is there a 'Complete' class, or does Analytic contain everything? - I'm confused as to why Descriptive contains the messageStartEvent and messageEndEvent, but no messageIntermediateEvent (throw or catch). I assume collaborations are involved (otherwise why have message events at all). But, without the ability to send and receive messages within the process flow, only a very small subset of collaborations could actually be modelled. So I'd think messageIntermediateEvents are necessary. - Why isn't TextAnnotation in the Simple class? Business models are very documentation-heavy. So I'd expect that TextAnnotation would be valuable for the simplest models. For this same reason, I'd expect the documentation attributes to also be in this class. - Groups and lanes tend to be used for similar use-cases. Given that LaneSets are in Descriptive, I'd expect that Groups would also. - There seems to be a number of missing attributes. For example, documentation, performer, everything related to data (ioSpecification, dataState, itemSubjectRef), serviceTask.operationRef, and so on. Were these truly missed or should I interpret this to mean they are only in the Complete class. - I would have expected performer in the Descriptive class, given that LaneSets are there, and the most common usage of lanes is to visualize performers. - You mention that example diagrams will be provided. That's an excellent idea. Recommend we also 'test' this proposal using sample XML. That'll give us a realistic sense of how well the interchange format can be partitioned along these classes. |
| Comment by Robert Shapiro [ 10/Mar/10 11:25 AM ] |
|
Suzette,
More work was done on conformance testing for XPDL2.1 after the specification came out. There is a page about conformance testing on the WfMC web site. There are other issues discussed there that have not been proposed for BPMN2.0; they pertain to conformance testing procedures for certification. However, the issue about being able to retain all the schema-correct xml in the serialization is specifically addressed: I quote from the web site: Import A tool must be able to import any XML document with the following three properties: 1. The document satisfies the XPDL 2.1 schema. 2. The document passes the structural integrity test performed by the XSLT. 3. The tool must not discard parts of the document that it does not understand (relevant only if the tool can also export). These may include: extended attributes, user name spaces and/or elements and attributes in a portability conformance class above that which the tool claims to support. If the tool claims graphical portability conformance it must be able to display the imported diagram if the diagram conformance class is equal to or a subset of the tool's conformance class. The displayed elements must use the defined BPMN shapes, line types and icons. The node and connector graphics info in the document should be used to determine the size and position of all displayed graphical objects. Critical to our discussion is point 3 above. In earlier discussions of the weekly OMG BPMN2.0 FTF a number of people felt strongly about tools having to be able to read and write any full-schema correct serialization. (You might check with Stephen White about this). This is a feature necessary to support round-trip interchange. That seems a worthwhile objective. In any case, the wording was meant to differentiate between 'import' and 'understand'. As to being able to write back out xml that the tool itself doesn't 'understand', I believe there are existing tools out there that manage the xml update without throwing away xml. Including material in a tool-specific namespace is just one example of this. |
| Comment by Suzette Samoojh (IBM) [ 12/Mar/10 06:01 PM ] |
|
Robert,
> This is a feature necessary to support round-trip interchange. That seems a worthwhile objective. It certainly is a worthwhile objection. My concern lies in whether it is an achievable objective, and what is the associated cost. Maybe it is achievable, maybe it is not. My gut feel is it is non-trivial. Hence, until we have done enough concrete analysis to determine it is achievable with reasonable cost, we're jumping the gun by burning it into the conformance requirements. > I believe there are existing tools out there that manage the xml update without throwing away xml. Including material in a tool-specific namespace is just one example of this. But how? I'm less worred about the tool-specific extensions ... they tend to be attributes that can be ignored. I can envision how this would work in simple cases. But there are many other cases where the problems are harder. If I could see some analysis or examples, describing common patterns that would be encountered and how such patterns could be solved while achieving round-tripping. That would go a long way to demonstrating this is achievable. Here is a concrete example to tackle: consider an Analytic-level process with an Event Based Gateway. Following the gateway are message intermediate events. What happens when that is imported into a Simple tool? What would that tool show its user (considering it has to keep the EBG and Message Events around in the model)? And what happens when the user starts making edits to whatever they see? |
| Comment by Suzette Samoojh (IBM) [ 12/Mar/10 06:18 PM ] |
|
From Bruce Silver:
Suzette, Robert asked me to comment on your issues as he is traveling. I don't have JIRA write access anymore, so hopefully you will post on my behalf... 1. Why message start/end but not intermediate in the Descriptive class? It is a good question. One of the major sources of these classes was my Level1/Level2 training methodology. L1 corresponds to the Descriptive class, L2 to the Analytic. Assigning all intermediate events to Level 2/Analytic was for 2 reasons: 1) some business people find them confusing; and 2) many BPMN tools do not support them. The whole idea of the conformance levels was that every BPMN tool should support the Simple class, most would support the Descriptive, fewer the Analytic, and fewer still the complete set. You might ask why have message start and end at all in Descriptive. Probably a better point, as many tools do not support message flows or collaborations at all. But I think good to encourage tool vendors to do it. Also, you can send and receive message flows from tasks, so throwing/catching intermediate message events are not "necessary" at L1. 2. Why Text Annotation is not included in Descriptive? I can't answer that, I thought it was. It should be. 3. What about Documentation attributes? What about any of the hundreds of other xml elements that do not print in the diagram? The conformance classes, as I understand them, were really about diagram-visible elements plus a minimum set of children and attributes required to hold the model together, e.g. ID, IDREF, event detail type. I would have no objection to Documentation as one of those children expected to be portable. 4. What about Group? Group is just a doodle. It has no semantics. Why not any scribble? It's pure graphics, as far as I know. Did it change from BPMN 1.x? Bruce Silver, Principal Bruce Silver Associates/BPMessentials 500 Bear Valley Rd Aptos CA 95003 831.685.8803 BPMS Watch: www.brsilver.com/wordpress |
| Comment by Suzette Samoojh (IBM) [ 12/Mar/10 06:18 PM ] |
|
Bruce,
Thank you for the input. To respond to your points ... 1. My belief is that tools (anything above simple) should support collaborations. It is one of the key value-adds of BPMN. So, anything that pushes tools in this direction would be a good thing. You are right that tasks could be used (I'd forgotten), so technically throwing/catching intermediate message events aren't necessary. But the lack of symmetry and difference in styles bothers me. Once a user is exposed to the concept of message events (and they would be through the message start and end events), it's not much of a stretch for them to understand the intermediate variations. So including them wouldn't create a whole lot of confusion IMO. Plus, it enables a user to adopt a consistent style to how they model sending and receiving of messages. 2. My questions was about Text Annotation in Simple. Why not include it? 3. I'd propose to add it then. The way I see it, documentation is an extremely important attribute, and one that should be available and interchangeable at all levels. 4. Ah but it's a standardized doodle and that elevates it above other 'doodles'. Otherwise, I would agree with you. A user that is 'drawing pictures' that describe their process model would make use of graphical features, and group is one such graphical feature in the spec. Someone creating executable models probably won't bother as much since groups aren't executable. Hence, if there's a level it belongs in, it's the ones that rely on graphical mechanisms rather than formal ones. Hence why Descriptive seems to fit. Thanks, Suzette |
| Comment by Suzette Samoojh (IBM) [ 12/Mar/10 06:19 PM ] |
|
From Bruce Silver:
Suzette, I don't disagree strongly with any of your comments. On intermediate message events, I suspect you just mean throwing and catching, not boundary (interrupting or non-interrupting). This is the slippery slope with intermediate events, because even though the serialization is completely different, in most tools it's just an intermediate message event for all of these until you place it in the diagram. So making some part of the class and some not... I don't know. Remember the goal is tool interoperability. Anyway, that's why I left all intermediate events out of L1/descriptive. Bruce Silver Principal, Bruce Silver Associates/BPMessentials |
| Comment by Suzette Samoojh (IBM) [ 12/Mar/10 06:31 PM ] |
|
Bruce,
Right. I did mean just throwing and catching, not boundary. I agree the boundary events don't belong in Descriptive. I understand your motivation now. I'd say that Descriptive tools could simply disallow placement of intermediate events on activity boundaries. I know most tools do little enforcement ... but that's another thing we need to encourage. Thanks, Suzette |
| Comment by Reiner Hille-Doering [ 18/Mar/10 10:24 AM ] |
|
Hi all,
so far all classes seem to be mainly relevant for BPMN tools that are intended for non-executable modelling. As tools targeting executable models need to care about much more attributes, but in some cases less elements, I added a proposal for a new class "common executable". You find it here: http://www.omgwiki.org/bpmn2.0-ftf/lib/exe/fetch.php?id=public%3Apresentations_examples&cache=cache&media=public:conformance_sub-class_executable_draft.doc Reiner. |
| Comment by Matthias Kloppmann (IBM) [ 19/Mar/10 03:57 AM ] |
|
@Reiner regarding a subset of executable conformance: This is the first time such an idea comes about. Considering the amount of work required to consolidate such a list and get agreement, I feel uncomfortable to work this as part of the FTF. Also, having a list of constructs that is yet another one, decoupled from the other conformance classes, would just add to the overall (real and perceived) complexity of the spec.
*If* we wanted to discuss an approach like that, I'd suggest to use the existing suggestions for "modeling" conformance classes and just expand them to cover execution, to the extent possible. That could be a possible topic for the RTF, if seen as clarification of the impact of conformance classes on execution conformance. |
| Comment by Reiner Hille-Doering [ 19/Mar/10 04:21 AM ] |
|
Matthias,
we had the discussion about the 4 modeling conformance levels proposed by Robert (simple, descriptive, analytical, complete) in the last Moday meeting before F2F. There we discussed that all 3 (except complete) are not very usefull for modeling tools that intend to create executable models. Therefore I propsed a 5th, which is in the attached document. (The other 3 are here: http://www.omgwiki.org/bpmn2.0-ftf/lib/exe/fetch.php?id=public%3Apresentations_examples&cache=cache&media=public:conformance_sub-class_draft_for_bpmn2_spec.doc ) So I indeed propose to have another "modeling" conformance class instead of another kind of conformance. PS: Is is also a valid discussion point if 5 classes are too much and e.g. SIMPLE or DESCIPTIVE could be dropped if COMMON EXECUTABLE would be added. |
| Comment by Robert Shapiro [ 19/Mar/10 09:01 AM ] |
|
After analyzing discussion points I have revised the proposal in the following way.
1: Text Annotation is added to the SIMPLE class. 2: Encouraging the use of Collaboration is a good idea. The DESCRIPTIVE class supports both Pools and Message Flow. The Message flow can be between Pools and between Activities in different Pools. It is not necessary to add Message Intermediate Events to support this. DESCRIPTIVE does not support intermediate events and this would be an unnecessary complication. 3: Add documentation attribute to DESCRIPTIVE. Documentation is not a visible attribute and had previously been left out of the subClasses. However, it appears to be both easy to support and in wide use by BPMN modelers. 4: Add Group to DESCRIPTIVE. It is a visual element that should be supported. 5: Performer has been proposed. It is not a visual attribute. Lanes are in the DESCRIPTIVE class and Lane name is commonly used to indicate 'role' although there is no defined semantics for it. Adding Performer to DESCRIPTIVE class would generate confusion. 6: dataState has been proposed. BPMN 1.x seems to have used State in conjunction with DataObject name to construct dataObject lables (name + [State]. However, a search of the BPMN 2.0 draft did not find any such description. This should be deferred. 7: A conformance sub-class has been proposed for executable models. While this may be a good idea, it is not in scope for this proposal which is specifically for the Process Modeling Conformance. |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:47 PM ] |
|
Robert,
2: To clarify, the proposal was to include the catch and throw Message Intermediate Events, not the boundary variation. I agree it is not technically necessary. But this move prevents users from adopting a consistent and popular modeling style when working at a descriptive level (i.e. consistently use message events for message exchanges). It also further complicates round-tripping (which is complicated enough). I don't quite buy the argument that it is an unnecessary complication. As a tool vendor, I can attest that this is hardly difficult to implement. And a user can't possibly be confused, given they're already exposed to message events (start and end). In any case, I'll voice my opinion one more time and state that I think leaving them out would be the wrong move IMO. But I won't push further. 5: I don't understand the argument. Why is "defined semantics" relevant to the descriptive subset. In any case, the LaneSet.partitionElement attribute is in the Descriptive set. When lanes are visualizing 'roles', you need the performer to make sense of the LaneSet.partitionElement value. So why is the LaneSet.partitionElement present in this conformance class? 6: I disagree. See |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:49 PM ] |
|
Robert,
Is there a "Complete" class? And what of the the attributes that don't appear in any list class. Is the implication that they only occur in the "Complete" class? |
| Comment by Suzette Samoojh (IBM) [ 19/Mar/10 04:59 PM ] |
|
Robert,
On the 'round-tripping' conformance criterion, the IBM position is that this is non-trivial and there is insufficient time to validate implementation feasibility. Hence it is too soon to burn this into the spec as a conformance requirement. We propose to change the requirement to simply require import of the full XSD: The tool must be able to import correct serializations that include elements and attributes not in the supported sub-class. |
| Comment by Robert Shapiro [ 20/Mar/10 08:35 AM ] |
|
Introducing Intermediate Events (even restricting them to non-boundary) at the DESCRIPTIVE level is an unnecessary complication which is not required for representing message flow between processes.
Required attributes for laneSet have been changed: laneSet has id, lanes with name, childLaneSet, flowElementRef. The lane name is what is visible in the diagram, labeling all lanes and sub-lanes. Discussion in the DI subgroup raise further questions about dataState given the introduction of dataObjectRef to handle multiple occurrences of the same data object, where each dataObjectRef can have its own name. I still suggest that this be deferred. The Complete class is Process Modeling Conformance as defined in the BPMN2.0 draft specification. Mentioned attributes in the sub-classes when present in a diagram must be schema-correct in the XML and thus require other elements. The problem with the suggested revision to require that a tool import any correct serialization is that it does not say what to do with elements not supported. For instance, does it simply not draw such elements? There are various possibilities, but to work this out in detail seems not possible in the timeframe of the FTF work. I suggest that we defer this requirement. |
| Comment by Robert Shapiro [ 24/Mar/10 08:18 AM ] |
|
Suzette and Reiner,
Should I prepare a proposal that consists of the DESCRIPTIVE and COMMONEXECUTABLE classes? My impression was that the FTF wanted an updated proposal posted by Thursday this week. Please let me know ASAP what you think. |
| Comment by Robert Shapiro [ 24/Mar/10 02:51 PM ] |
|
In response to the FTF discussion and conversations with other FTF members, I have posted two new proposals. This gives us three alternatives to consider:
1: SIMPLE, DESCRIPTIVE, ANALYTIC classes; the original proposal 2: DESCRIPTIVE, COMMONEXECUTABLE; This retains the high-level DESCRIPTIVE and adds Reiner's execution-oriented class. 3: DESCRIPTIVE, ANALYTIC, COMMONEXECUTABLE; This includes ANALYTIC which is based on significant analysis and inputs from the Department of Defense Architecture Framework user community. At the next FTF we can jointly choose which proposal should go on the ballot. |
| Comment by Dave Ings [ 24/Mar/10 03:45 PM ] |
|
One of the discussion points has been that the "analytic" level could/should be aligned with the requirements of the OMG UPDM user and vendor community (indeed I am led to believe that community had input to the analytic proposal).
OMG is meeting this week and we were hoping to get more information about whether adding "analytic" would satisfy their requirements and (perhaps) reduce or obviate the need for a DODAF/MODAF aligned UML profile for BPMN 2.0. Early reports from OMG indicate that some community opinion is in favour of issuing an RFP for such a profile, in which case a rethink of the use case may be required. I hope to get additional status on this later in the week. |
| Comment by Suzette Samoojh (IBM) [ 24/Mar/10 04:10 PM ] |
|
Assuming there is no longer push to have an analytic level that is aligned with the UPDM requirements (see Dave's comment above), here is an additional proposal based on my comments in Monday's meeting:
4: DESCRIPTIVE: only the descriptive level as it is described in proposal 1 |
| Comment by Robert Shapiro [ 24/Mar/10 04:39 PM ] |
| Michael zur Muehlen, the author of the DODAF conformance class would like to speak on the issues raised by Dave Ings. I suggest that he contribute to the discussion on Monday. |
| Comment by Justin Brunt (TIBCO) [ 25/Mar/10 11:34 AM ] |
|
I'm not able to attend the 3/29 meeting so won't be able to put my view forward on this.
Although SIMPLE is a good confidence builder when starting out I feel that it doesn't contain enough to really determine usefulness. So I don't think that it would be a great loss if we didn't proceed any further with it. However, at the other end of the spectrum I really believe that ANALYTIC holds real value. As developers of BPM modeling tools we all have ideas of what are important and what are't important BPMN constructs. However, experience has taught me that we're sometimes a bit too far removed from the people who actually use these tools to produce process models. What Michael has done is to engage with people at the sharp end of process modeling and discover what they find useful and important aspects of BPMN. I don't think that it's important that this work started out in the world of the DoD. In over 16 years of my involvement of BPM I have learnt that there is a lot of commonality between the way processes are modeled in different business sectors. I would, therefore, see the DoDAF work as a worthwhile and free gift to our cause in making BPMN 2.0 really applicable to the users of the tools that support BPMN 2.0. My vote is, therefore, to retain the ANALYTIC conformance calss. |
| Comment by Dave Ings [ 25/Mar/10 02:25 PM ] |
|
First let me state that IBM is not opposed to an additional conformance class or two based on real world experience, as long as they map to widely accepted use cases.
However let me ask (out loud) whether this activity wouldn't be best left until we have more extensive experience in the "real world" with the 2.0 level of the spec as crystallized in products that end users actually have field experience with |
| Comment by Mariano Benitez (Oracle) [ 25/Mar/10 02:58 PM ] |
| Co-Chairs moved to Ballot 11. |
| Comment by Robert Shapiro [ 30/Mar/10 12:57 PM ] |
| The file contains the proposed resolution, as decided at the FTF meeting on March 29 2010. |
| Comment by Suzette Samoojh (IBM) [ 01/Apr/10 05:58 PM ] |
|
Robert,
You earlier stated that some diagrams would be included in the spec, to illustrate each of the classes. Are those available for review? I had suggested you include some XML examples to test that the classes are expressable with our schema. Has this been done? This is extremely important. Descriptive: - Given that DataAssociation is included, you will need additional attributes on activities and events for them to be valid based on our current spec, schema, and metamodel. One end of the DataAssociation is always a DataInput or DataOutput. Specifically you will need: IOSpecifications, DataInput, DataOutput, DataInputAssociation, and DataOutputAssociation. - I see that MessageEventDefinition is included, but Message is not. And yet MessageEventDefinition has a reference to Message. So do you only intend a subset of the MessageEventDefinition attributes to be included in the subclass? And if yes, shouldn't that subset be identified for consistent interchange? - I noticed that Link Events aren't in any of the levels. Link Events are extremely important to modelers creating large documentation-level models. So don't see how we could have a 'Descriptive' level without them. Re: Analytic: - SendTask/ReceiveTask: The MessageRef attribute is present in neither, and yet Messages are part of this subclass. Was this an accident? If not, what's the reasoning for omitting this attribute? - Can you please itemize what's not in Analytic? It's very difficult to assess otherwise. I only just noticed that Link Events are not present anywhere, which is a major major gap imo. It's hard to tell if there are other important pieces still missing. Re: Common Executable - Will there be a full proposal posted soon? I see questions and discussion points still in here ... e.g. eventBasedGateway says "(eventGatewayType - maybe disallow on start)". And dataAssociation says "transformation??". So looks like this is still a work-in-progress. Correct? - Catching message IE lists a "Correlation" attribute. There is no such attribute. Do you mean CorrelationKeys? But CorrelationKeys exist in Collaborations only. |
| Comment by Suzette Samoojh (IBM) [ 01/Apr/10 06:17 PM ] |
|
I just want to highlight two of the problems I point out above. These are issues that essentially mean you cannot create interchangeable XMLs for Descriptive or Common-Executable that are valid.
Given how critical interchange is (that's why we're doing this right?), these would really have to be addressed for this to work as intended. [Now you see why I keep pushing on the XML examples to test the proposal.] The two problems are: - Descriptive: DataAssociations are included, but DataInputs and DataOutputs are not. And yet the source or target of a DataAssociation must be a DataInput/Output. Net is you cannot create a valid BPMN model that makes use of DataObjects and DataStores using the contents of the current subclass. - Common-Executable: There is a Correlation attribute listed for MessageIntermediateEvents. But no such attribute exists in the schema. If Correlation is needed, then Collaborations are needed in the proposal (which implies Participants, MessageFlow and such also get dragged along). |
| Comment by Gary Brown [ 03/Apr/10 06:33 AM ] |
|
(Comments from Kris Verlaenen of RedHat)
<loopCharacteristics>: which types of loop characteristics (standard / multi-instance) and which attributes need to be supported? <userTask>.<resources>: does this include humanPerformer, potentialOwner? It might be useful to include the elements that are indirectly referenced as well: <definition>, <process>, <itemDefinition>, <resource>, <message>, <error> It might be useful to also include the <property> element (both on the process and subProcess element). While a dataObject is the visual counterpart of property, forcing the definition of all properties as a visual dataObject might make processes more complex than necessary. Supporting <property> would allow users to define properties without them showing up on the process diagram. <gateway>: the specification mentions best practices (and the possibility of a modeling tool to enforce these) like: - only converging / diverging, not mixed? - only allow multiple incoming connections on gateways, not on other flow elements (i.e. only explicit gateways)? It might be a good idea to restrict this subclass to only these best practices? |
| Comment by Robert Shapiro [ 03/Apr/10 07:58 AM ] |
|
Visualization of Example in ANALYTIC sub-class. An attached Zip folder contains Visio diagram, BPMN2.0 serialization (without BPMNDI) and picures of main process with one collapsed subprocess. |
| Comment by Robert Shapiro [ 03/Apr/10 08:16 AM ] |
|
Zip file contains:
1: BPMN Visio Diagram of Standard Process, an example of the ANALYTIC conformance sub-class. 2: BPMN 2.0 serialization. 3: JPG of Standard Process. 4: JPG of Process Application embedded sub-process. |
| Comment by Robert Shapiro [ 04/Apr/10 10:39 AM ] |
| Updated spreadsheet of conformance subclass elements with list of visible elements not included in any sub-class. |
| Comment by Robert Shapiro [ 04/Apr/10 10:42 AM ] |
| Updated[4/4/10] version of proposal. |
| Comment by Robert Shapiro [ 04/Apr/10 10:46 AM ] |
|
Questions from Suzette:
Diagrams: I Have uploaded an example in the ANALYTIC sub-class. DataAssociation: DataAssociation is Abstract. In the XML document you will see either dataInputAssociation or dataOutputAssociation. I will comment that in the proposal. For data flow, we don't need ioSpec, dataInput, and dataOutput in non-executable models. In BPMN 2.0, dataAssociation always connects an activity or event to/from a dataObject, and is described in BPMN as a child of the activity or event. One end of the association is a ref to the D.O. The other end is - in the schema - a ref to a dataInput or dataOutput of the activity or event that is the parent of the dataAssociation. Descriptive and analytic are meant to focus just on info in the diagram, and normally dataInput and dataOutput are not shown in the diagram. There are shapes for it but are outside the conformance classes. So how do you reference them in the xml? Two alternatives: The first one Bruce Silver proposed during the development of the spec but was not accepted and is not allowed by the current xsd: make the ref to the dataInput or dataOutput optional in xsd and not included in the conformance class. The second one has the dataAssociation source or target ref point to the event or activity itself, not to a particular dataInput or dataOutput. In other words, as far as descriptive or analytical model is concerned, the data flow connects just to "the event" or "the activity", not to a specific dataInput or dataOutput, which would be part of the executable model. The attached file does it the second (schema-valid) way. Message: MessageRef is optional and not needed in the DESCRIPTIVE sub-class. In general, if the sub-class doesn't mention an attribute and it is not required by the schema then it is not in the subclass. LinkEvent: LinkEvent was in an early proposal for DESCRIPTIVE and subsequently removed. Link is an Intermediate event (of sorts) and as such I will put it in ANALYTIC. My next posting of the proposal will contain it. ANALYTIC: MessageRef is optional and not needed in the ANALYTIC sub-class even if message is in the subclass. An updated spreadsheet was posted to the wiki with a list of those elements not included in ANALYTIC. I will attach that spreadsheet to the JIRA. COMMONEXECUTABLE: Awaiting response from Reiner. |
| Comment by Robert Shapiro [ 04/Apr/10 10:48 AM ] |
| I am reviewing the comments from Gary Brown/Kris Verlaenen and will post a reply. |
| Comment by Robert Shapiro [ 04/Apr/10 03:16 PM ] |
|
Gary Brown_Kris Verlaenen
standardLoopCharacteristics: no further attributes required multiInstanceLoopCharacteristics no further attributes required For both of these the sub-class needs only enough to provide the visual identification. userTask: only id and name. property: not included. Note that we do not preclude a tool providing this information. It just plays no role in the visualization and may not be supported by another tool that supports these sub-classes. gateway: I don't think the converging/diverging/mixed attribute should be part of the class. I would not remove mixed from the class; it is a slippery slope when you try to infer "best practices". This suggestion would be objectionable to some of the tool-vendors and analysts who have expressed interest in portability. |
| Comment by Suzette Samoojh (IBM) [ 05/Apr/10 07:30 PM ] |
|
Robert,
Thanks for the examples and updated spreadsheet. This is helpful. Did you intend to include the pictures in the spec? - Data associations The attached file may be schema-valid, but it is not BPMN-valid. A tool that follows the spec will reject it as semantically invalid. A tool that uses the XMI interchange format will reject it as syntactically invalid. See Figure 10.61 in the Beta spec (pdf pg 230). The source and target of the data associations MUST be item aware elements. The spec is very clear about this, and describes this requirement in many many places. The conformance classes as they currently are can only be satisfied by tools that ignore the standard. This obviously will not do. > In general, if the sub-class doesn't mention an attribute and it is not required by the schema then it is not in the subclass. Then let's state that somewhere in the proposal. If it isn't, tools will assume something very different. I certainly did, and looks like Kris did also. And then there goes any hope of interchange. - Link Event This is a mistake. A belief about implementation difficulties (one I don't agree with, and I know what it takes to implement these) should not be the only driving criteria. At what point does actual user requirements and field experience take precedence? Link Events are heavily used when creating large models for documentation. They belong in the Descriptive class. > MessageRef is optional and not needed in the ANALYTIC sub-class even if message is in the subclass. Why? I see it's not there. But I haven't seen a justification for it not being there. Why bother including Message if nothing is referencing it? - Missing elements list I was very surprised by some of what is in the 'missing elements' list in the spreadsheet. I would expect several of them to appear in Analytic. As an example, I know of customers that create non-executable models, but who make use of the compensation constructs. They do so to document their 'undo' steps in the event of a problem. Did you assume those constructs were only relevant to executable models? If yes, my first-hand customer experience is the opposite. Comments to your responses to Kris: > userTask: only id and name A common analytic/simulation use-case is to look for resource bottlenecks. You can't do that without specifying performers. Performers should be in any class called "Analytic". > For both of these the sub-class needs only enough to provide the visual identification. I'm very confused. I thought only the Descriptive class was driven by what you see in the diagram. I didn't realize Analtyic was also. And why is it? It is starting to sound closer to a 'Detailed Descriptive' class rather than an Analytic class. Certainly it wouldn't satisfy several Analytic use-cases that I'm aware of and doesn't match what users who do Analysis will make use of. Can you provide a list of the driving principles behind the Analytic class (behind all of the classes really): Who is the target audience of each, and what are their goals. I keep finding myself very surprised by some of the details and responses ... my belief of what should go into each of the classes based on their names and descriptions keeps getting shot. Otherwise, it is difficult to judge if the content is appropriate for the class it is in. |
| Comment by Gary Brown [ 06/Apr/10 07:12 AM ] |
|
(Comments from Kris Verlaenen of RedHat)
Robert, Sorry, a part of the context information got lost when copying the remarks to the JIRA issue. I have been reviewing the common executable subclass, and the remarks I made before were about that subclass. But this information got lost, sorry about that. Since this subclass is about specifying executable process models, I assume not only the visual elements are important. Could you revisit the remarks (I added the relevant ones below): <loopCharacteristics>: which types of loop characteristics (standard / multi-instance) and which attributes need to be supported? <userTask>.<resources>: does this include humanPerformer, potentialOwner? It might be useful to include the elements that are indirectly referenced as well: <definition>, <process>, <itemDefinition>, <resource>, <message>, <error> It might be useful to also include the <property> element (both on the process and subProcess element). While a dataObject is the visual counterpart of property, forcing the definition of all properties as a visual dataObject might make processes more complex than necessary. Supporting <property> would allow users to define properties without them showing up on the process diagram. Kris |
| Comment by Reiner Hille-Doering [ 07/Apr/10 05:02 AM ] |
|
Answer to Suzette and Gary about COMMONEXECUTABLE:
The current posted version is still kind of draft and I will refine it and consider your suggestion. I'll do so in the next few days. Reiner. |
| Comment by Suzette Samoojh (IBM) [ 07/Apr/10 05:11 PM ] |
|
Reiner,
One other question. I noticed that the start message event, end message event, and catch intermediate message event are here. But the throw intermediate message event is not. Was that accidental? I find the asymmetry rather 'weird'. |
| Comment by Robert Shapiro [ 09/Apr/10 12:03 PM ] |
| Latest update. Responds to issues raised in recent comments (April 9) |
| Comment by Robert Shapiro [ 09/Apr/10 12:07 PM ] |
| This document discusses the personas for the proposed sub-classes. |
| Comment by Robert Shapiro [ 09/Apr/10 12:21 PM ] |
|
Revised proposal contains an updated version of the COMMONEXECUTABLE sub-class in response to suggestions made by Gary, Kris and Suzette. Also minor changes in response to Suzette's remarks on DESCRIPTIVE and ANALYTIC. I will comment on DataAssociation later this week. As far as messageRef is concerned, there is no longer a visible depiction of message for message events or tasks (recent changes in the specification). For messages in ANALYTIC assovciated with messageFlow, the messageRef attribute of messageFlow is required.
Both DESCRIPTIVE and ANALYTIC are concerned with what is visible in the diagram. I have uploaded a document that describes the persona for each sub-class. |
| Comment by Robert Shapiro [ 12/Apr/10 10:20 AM ] |
| Updated to deal with dataAssociation metamodel issues. |
| Comment by Robert Shapiro [ 12/Apr/10 10:22 AM ] |
|
The following has been added to the description of dataAssociation in the proposal:
*** dataAssociation is ABSTRACT: dataInputAssociation and dataOutputAssociation will appear in the XML serialization. These both have required attributes[sourceRef and targetRef] which refer to data-aware elements. To be consistent with the metamodel, this will require the following additional elements: ioSpecification, inputSet, outputSet, dataInput, dataOutput. When a BPMN editor draws a dataAssociation to an Activity or Event it should generate this supporting invisible substructure. Otherwise, the metamodel would have to be changed to make sourceRef and targetRef optional or allow reference to non-data-aware elements, e.g. Activity and Event. |
| Comment by Reiner Hille-Doering [ 16/Apr/10 03:28 AM ] |
| Update: Remove Correlation (with corresponding internals note) from COMMONEXECUTABLE conformance type, as making correlation required would make a lot of addtional classes and attributes mandantory. Of cause vendors can support correlation, but the conformance type does not require it. |
| Comment by Ivana Trickovic [ 19/Apr/10 04:05 AM ] |
|
Supporters of the conformance sub-types proposal:
SAPERION AG EFG Consulting Ltd Raytheon iG, Brasil DUNA, Spain Statoil ASA Computas AS Visionest Fraunhofer-Institut für Software- und Systemtechnik ISST Quotes ======= "Following the request of Bruce Silver (http://www.brsilver.com/wordpress/2010/03/29/bpmn-tool-interoperability-make-your-voice-heard/#comments) I want to notify that SAPERION (and Signavio, see CC addresses) want to support the interchange of BPMN 2.0 models from other vendords to SAPERION Workflow. We ar currently working on a Transformation Service which will allow to import models designed by Signavio Process Editor first. But this should work for other vendors as well. Signavio want to be able to import models from other vendros as well. This is the our preferred way to handle other models as well." Dr. Martin Bartonitz, SAPERION AG "I would very much appreciate it you could convey my support for tool interoperability to be included in the final BPMN 2.0 specification. As an advocate of BPMN I have long felt that the implementation of tool interoperability would remove on of the few issues that practitioners have with the adoption of BPMN." Simon Parkinson, EFG Consulting Ltd "Raytheon (a global defense and electronic company) to support the Conformance Class proposal. We have been evaluating products from SAP, Oracle, and others to support Business Process Modeling and integration into SOA foundations, and we need to see a mechanism in place that enables an evolution for levels of BPMN compliance with a rich set of integration possibilities among other tools within our enterprise. I am the BPM Champion within my company and can talk to where we have business needs in this space over the next couple years." J Bryan Lail, Raytheon "BPMN2.0 tool interoperability is essential for long term adoption, the situation should be the same we have in the browser world. A few days ago another big software manufacturer (http://www.adjb.net/post/Microsoft-Fails-the-Standards-Test.aspx) failed honoring standards. Supporting the BPMN2.0 Process Modeling Conformance Class proposal would be redundant in important benefits for costumers and manufacturers, improving a common core instead of developing independent and proprietary technologies. Corba fails just for similar reasons, if WEB technologies have had such success is because they focus in interoperability offering test for browsers and tools." Antonio López-Cerón Vivo, Innovación Tecnológica, DUNA "We have a long standing interest in Workflow language standardization and execution, so we are watching closely the BPMN effort. We strongly support Bruce Silver's "BPMN2.0 Process Modeling Conformance Class" proposal, since we think it may well serve the industry need for a language able to describe, model and execute business processes in a vendor-indipendent way. We kindly ask you to express this support in the BPMN 2.0 standardization process and to forward our support to the voting members of the process." Michele Mauro, Visionest "We as a member of a big applied research organisation in Germany are much interested in BPMN 2.0 and a practical specification of conformace classes to make exchange of models between different tools work. As Bruce Silver and Robert Shapiro worked out, the defined conformance classes in the latest BPMN 2.0 version are not detailled enoth, a refinement on attribute level is absolutely nesseccary. I herewith support the proposal of Robert Shapiro (http://www.brsilver.com/wordpress/wp-content/Conformance-DESCRIPTIVE_ANALYTIC_EXECUTABLE-proposal-for-B%E2%80%A6.pdf) and I ask you herewith to forward my message to all of the FTF voting members." Norbert Weißenberg, Fraunhofer-Institut für Software- und Systemtechnik ISST |
| Comment by Ivana Trickovic [ 11/Jun/10 10:51 AM ] |
|
spec-May24-review
[AB feedback] Feedback from Steve Cook, Microsoft: Resolution 14240 promises to copy the content of a document describing conformance. The copy has not been done, so the report is incomplete for this resolution. |
| Comment by Ivana Trickovic [ 11/Jun/10 10:51 AM ] |
|
As per the 6/7 meeting:
Add to the errata document explanation where the resolution document can be found. The final report can be changed accordingly. |
[BPMNFTF-2] [OMG 14223] Allow a Process to be Ad Hoc (in addition to a Sub-Process)
|
|
| Status: | Deferred |
| Project: | OMG BPMN FTF |
| Component/s: | Notation, Process Orchestration, Semantics |
| Affects Version/s: | None |
| Fix Version/s: | Ballot 9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Mariano Benitez (Oracle) | Assigned To: | Stephen White |
| Resolution: | Unresolved | Votes: | 0 |
| Description |
|
##Source: International Business Machines (Dr. Stephen White, wstephe@us.ibm.com)
Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used ##Proposed Resolution: Defer The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue. |
| Comments |
| Comment by Stephen White [ 04/Nov/09 03:16 PM ] |
|
---------- Discussion during Process Orchestration Sub-Group on 2009-10-28 ----------
We agreed with the idea. A proposal will be generated |
| Comment by Ivana Trickovic [ 09/Mar/10 11:22 PM ] |
|
As per March F2F Meeting:
- This is a request for new feature. The proposal is to close (out of scope) it with no changes to the specification |
| Comment by Stephen White [ 15/Mar/10 03:34 PM ] |
|
---------------- Proposal --------- 2010-03-15 --------------------------------
The FTF agrees that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF ----------------------------------------------------------------------------------------- |
| Comment by Stephen White [ 15/Mar/10 03:35 PM ] |
| New Proposed Resolution |
